Subject: [TLS] Query regarding generating client_write_key.

From: nilesh <[email-masked]>
Date: Tue, 27 Sep 2011 14:23:07 +0530

Hi,

I am new to the TLS/Cryptography and started working on decrypting the 
packets over SSL/TLS.
I have followed the RFC2246, 5246.

To start decoding the packets, I need to have symmetric keys 
(client_write_key/server_write_key).
I have the key_block, IV and MAC. As per the rfc:

client_write_key = PRF{key_block[32..36], client_random, server_random, 
some_string}[0..31];
And I have started writing PRF (pseudo-random function) somewhat like:

<snip>
/*
  input : has 5bytes data i.e. key_block[32..36];
  salt1 == client_random, salt2 == server_random, salt = 'A'.
*/
for (i = 0; i < 2; i++)
{
	MD5_Init(&md5);
	MD5_Update(&md5, (unsigned char *) &input[0], 3);
	// MD5_Update(&md5, shasig, 20);
	MD5_Final((unsigned char *)&md, &md5);
	
	SHA1_Init(&sha);
	SHA1_Update(&sha, pad, i + 1);
	SHA1_Update(&sha, (unsigned char *) &input[2], 3);
	SHA1_Update(&sha, salt1, 32);
	SHA1_Update(&sha, salt2, 32);
	SHA1_Final(shasig, &sha);
}
</snip>

Now, we need to XOR the md and shasig to get the bytes in client_write_key.

Queries:
1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be 
20bytes.
But the key we expect should be 32bytes (iterated the MD5/SHA1 twice for 
that). How could this be achieved?
2. Any suggestions on if the PRF() is designed somewhere? Pointers on 
how it could be designed?

I tried several ways, but getting the wrong key. Could someone please 
advice?

-- 
Thanks,
Nilesh

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 27 Sep 2011 16:05:21 +0200

> I have followed the RFC2246, 5246.
...
> But the key we expect should be 32bytes (iterated the MD5/SHA1 twice
> for that). How could this be achieved?

Did you read section 5 of RFC 5246?  It explains how the PRF function
works.

/Simon

---

From: Joshua Davies <[email-masked]>
Date: Wed, 28 Sep 2011 11:33:12 -0500

Are you implementing TLS 1.0/1.1 or TLS 1.2?  The PRF changed in 1.2.

The PRF is by far the most complex part of the implementation - if you
really want to understand it, I'd recommend chapter 6 of my book ; )
 However, you can download the companion source code for free from
http://media.wiley.com/product_ancillary/16/04709204/DOWNLOAD/920411%20implementing_ssl_gcc.zip;
take a look at the ch06/prf.c file.  It was written to be as straightforward
and self contained as possible, and it includes a standalone main routine
that you can use to pass in arbitrary secrets/seeds/labels and see exactly
what the PRF function generates.

On Tue, Sep 27, 2011 at 3:53 AM, nilesh <[email-masked]> wrote:

> (client_write_key/server_**write_key).
> 2. Any suggestions on if the PRF() is designed somewhere? Pointers on how
> it could be designed?
>
> ______________________________**_________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Joshua Davies <[email-masked]>
Date: Fri, 30 Sep 2011 09:22:58 -0500

On the contrary - the entire SSL handshake is sent in the clear - this is
why its important that both sides keep a running digest of the entire
handshake sequence and compare notes at the end, after encryption keys have
been exchanged (see RFC 2246, 7.4.9).  The first encrypted message in the
handshake is the "finished" message.  If you're using Wireshark/Ethereal to
sniff packets, it will decode the protocol details for you - if you're using
a non-standard port (say, testing on 8443), you'll need to select
analyze->decode as->SSL.

On Thu, Sep 29, 2011 at 12:50 PM, Tayade, Nilesh <[email-masked]
> wrote:

> Thanks a lot Davies. The source code was a lot helpful.****
>
> ** **
>
> Also I have another query – while observing the https packets on wire, I
> could see besides the SYN, SYN-ACK, ACK rest all the packets are encrypted.
> ****
>
> So after the socket is created (ACK from client is sent) – the client-hello
> is sent from client side in case of TLS/SSL. But what is this message
> encrypted using? The certificates aren’t exchanged yet, so we don’t know
> server’s keys.****
>
> ** **
>
> *From:* Joshua Davies [mailto:[email-masked]]
> *Sent:* Wednesday, September 28, 2011 10:03 PM
> *To:* Tayade, Nilesh
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Query regarding generating client_write_key.****
>
> ** **
>
> Are you implementing TLS 1.0/1.1 or TLS 1.2?  The PRF changed in 1.2.****
>
> ** **
>
> what the PRF function generates.****
>
> ** **
>
> On Tue, Sep 27, 2011 at 3:53 AM, nilesh <[email-masked]>
> wrote:****
>
> Hi,
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls****
>
> ** **
>