s->s3->tmp.key_block
s->s3->tmp.key_block_length

I think, these are the variables you are looking for..  Memory for the
key_block is allocated in ssl3_setup_key_block() or tls1_setup_key_block()
functions. Key Block contains keys and IVs in the following order as
specified in RFC.

      client write MAC key
      server write MAC key
      client write encryption key
      server write encryption key
      client write IV(if applicable)
      server write IV(if applicable)

Thanks,
Thulasi.


On Thu, Feb 7, 2013 at 3:42 AM, T J <jordan.tre...@gmail.com> wrote:

>
> 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
>

Reply via email to