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.pdf
As per this the last 128 bits of the expanded key will be the key that I am looking for. I extracted that and was able to decrypt the message successfully.
Thanks all the same.
On Fri, Nov 16, 2018 at 12:19 AM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
> On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users <openssl-users@xxxxxxxxxxx> 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, since the hardware crypto did not understand the record type.)
>
> Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL:
>
> https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt
> https://github.com/openssl/openssl/pull/5253
Well, it takes more than just extracting a key. One also needs to know
the cipher mode, and if not AEAD then the MAC algorithm and whether the
EtM extension has been negotiated, and with TLS 1.3 be prepared to
process keyUpdate messages, post handshake session tickets, ...
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Best Regards,
Hemant Ranvir
"To live a creative life, we must lose our fear of being wrong." - J.C.Pearce
"To live a creative life, we must lose our fear of being wrong." - J.C.Pearce
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
