Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

In Section 6.3 of the RFC for TLS 1.2, it is written that the key_block is derived from the following formula:

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +
                  SecurityParameters.client_random);

An arbitrary amount of "key_block" formulas are run until enough keying material exists to populate keys for the following six session keys:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

Unless I'm missing something, since values fed into the Key_block calculation are identical and don't change, the result of each calculation is the exact same string. Given that, why would the RFC indicate to recalculate the PRF when we could just repeat the same string as necessary to populate the six session keys?

After writing that out, I realized that I'm taking PRF to effectively mean "Hash of the following values". If I've misinterpreting PRF, then maybe the more appropriate questions would be:
Does each iteration through the Key Block calculation produce different results by nature of what a PRF is?
If so, how does the opposite end of the negotiation come to the same session keys?

share|improve this question

1 Answer 1

up vote 4 down vote accepted

Yes, you're misinterpretting the PRF.

It's not just a hash function (and when you hit the end of the function function, start back at the beginning).

Instead, if is a function that generates a rather long (actually, infinite) output; we use the first $N$ bits of that output to populate the various key values.

See section 5 of RFC5246; we have:

TLS's PRF is created by applying P_hash to the secret as:

 PRF(secret, label, seed) = P_<hash>(secret, label + seed)

where

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                        HMAC_hash(secret, A(2) + seed) +
                        HMAC_hash(secret, A(3) + seed) + ...

and A() is defined as:

 A(0) = seed
 A(i) = HMAC_hash(secret, A(i-1))

As you can see, until you hit a loop within the internal A function (which is quite unlikely to happen for a while), the PRF output will not repeat itself.

And, to answer your question "does both sides compute the same value", the answer is "this process creates a long output, but determanistically; both sides do generate the same PRF output"

share|improve this answer
    
I see. Thanks for the explanation. So a PRF is similar to a Hash, in that it takes input values and produces a "representative" sample of those values, except that a PRF can produce an arbitrary length result. If two people have the same starting data, and use the same hash function within the PRF, and are trying to acquire the same length data, they will always end up with the same final value. (correct me if I'm wrong). –  Eddie Apr 2 at 22:53
    
@Eddie: you are correct, except that PRFs in general do not produce arbitrary long outputs; that is a special property of the PRF that TLS uses –  poncho Apr 3 at 1:45
    
Nit-pick: "TLS's PRF" should actually be "TLS's TLS PRF". The construct you describe is called "TLS PRF" and is recommended, but not strictly mandatory for new cipher suites. –  Henrick Hellström Apr 3 at 10:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.