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-us...@dukhovni.org>
wrote:
> > On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users <
> openssl-users@openssl.org> 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*
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
