On Wed, Jan 30, 2013 at 06:15:27PM +0000, Viktor Dukhovni wrote:
If the OP does not mind potential future binary compatibility
issues, and is willing to use non-public interfaces, then
the master secret can be accessed via:
SSL *ssl;
/* ... */
SSL_SESSION *sess = SSL_get_session(ssl);
/* Internal interface */
int mlen = sess->master_key_length;
unsigned char *mkey = sess->master_key;
/* Internal interface + The handshake protocol MUST NOT be SSLv2 */
unsigned char *crand = ssl->s3->client_random; /* SSL3_RANDOM_SIZE */
unsigned char *srand = ssl->s3->server_random; /* SSL3_RANDOM_SIZE */
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...
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?
Question 2: Where do the client_random and server_random values come
from and what are they for?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
