david wong

Hey! I'm David, cofounder of zkSecurity and the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.

Distinction between the TLS PRF for the Master Key and for the Keys posted March 2016

Last time I wrote about TLS pre-master keys and master keys.

I just realized one more thing in TLS that doesn't make sense (besides the fact that different versions of TLS have different PRFs). Here's RFC 5246 (the RFC on TLS 1.2) on how to use the PRF transform your pre-master key into a master key:

key expansion

Here's the same RFC on how to use the PRF to transform your master key into your 4 or 6 keys:

premaster key

Noticed anything?

Took me some time, the first takes the server random appended to the client random, while the second takes the client random appended to the server random. I'm willing to bet this is not to circumvent any attack but rather to confuse the implementer...

Well done! You've reached the end of my post. Now you can leave a comment or read something else.

Comments

Avineshwar

Just came across your blog, was a good read all along.

Now, to your point, I do agree that it is not to circumvent any attack (if it would, then upon checking the implementation of the PRF, which might then again lead to an implementation of some hash, we might found that hash is having some issues).

On the other hand, I think of the following points:
>> It seems to me that the RFC is written like that to re-enforce the idea to a reader that the order does not matter.
>> That can also have some potential in weakening an implementation depending upon the implementation or some hash itself. The same applies to any similar use-case.

Some kind of explanation around that (that it is benign) and code-level enforcement around the ordering seems a valid point to look into.

leave a comment...