Sorry to keep hammering away at this, but I think I am missing something
here.
OpenSSL does all this for a TLS connection anyway right? I mean, after a
handshake, encryption keys, IV's etc are generated so that the TLS
connection can use them for encrypting/decrypting data. Surely I
shouldn't have to reinvent the wheel and do what OpenSSL already does...
All I want to do is get those keys, after the connection has been
established and use them directly in my own app instead of using the SSL
connection normally. Isn't there something like ssl->s3->final_key ?
On 01/02/13 17:26, Viktor Dukhovni wrote:
On Fri, Feb 01, 2013 at 10:05:15AM +1300, T J wrote:
These are sufficient to generate a session unique key via a suitable KDF
salted with an application-specific string.
OK, great. So I get the master key and run it through the a KDF and
I get a 256 bit encryption key for use in my application. Sounds
easy...
Not just the master key, also the client_random, server_random
(from the SSL handshake) and a *fixed* application-specific salt,
that yields a different key than another application might derive
under the same conditions.
Question 1: previously, you said:
... the expansion function of HKDF is a reasonable choice. ...
but now you mention salt which implies I should also use the
extraction stage. If the salt is random, doesn't that mean the
client and server would end up with different keys?
The salt is the same on client and server.
Question 2: Where do the client_random and server_random values
come from and what are they for?
The SSL handshake, IIRC the master secret does not change when a
session is reused, but client random and server_random do.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
