Hi Todd,
That is exactly what I am trying to do. The final goal is to implement
this in hardware. Anyways I figured out that the key expansion routine is
slightly different, more specifically the equivalent inverse cipher routine
defined in: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197
> On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users
> wrote:
>
> I have seen this done for hardware acceleration; where the crypto chip can do
> everything except the handshake.
> (In fact, this mechanism protected at least one device that I know of from
> the Heartbleed debacle, sinc
I have seen this done for hardware acceleration; where the crypto chip can do
everything except the handshake.
(In fact, this mechanism protected at least one device that I know of from the
Heartbleed debacle, since the hardware crypto did not understand the record
type.)
Look at how the kernel
> On Nov 14, 2018, at 6:54 AM, Hemant Ranvir wrote:
>
> My main goal here is to use openssl for initial handshake sequence. Once the
> connection is established between server and client, decrypt the incoming
> message (this time not using the openssl api but rather by using the decrypt
> A
I have implemented AES 128 encrypt and decrypt functions and tested it with
sample data and it checks out perfectly. I used the following reference:
https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf
Next I implemented a dummy SSL client and SSL server which uses openssl to
send and receive
