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:
--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."
On Nov 14, 2018, at 6:54 AM, Hemant Ranvir <hemantranvir@xxxxxxxxx> 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 AES function implemented earlier)
This makes no sense, because TLS does not just emit a simple CBC encrypted stream
after performing the handshake. So you can't do that. Use SSL_read()/SSL_write,
and let the library do the message decryption/encryption for you. When done use
SSL_shutdown() to cleanly terminate the stream, and depending on the application
protocol, make wait for the peer's SSL_shutdown() in turn to avoid truncation
attacks where completion of the stream is not implied by the higher level protocol.
--
Viktor.
--
openssl-users mailing list
To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-users
|
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
