In section 6.3. Key Calculation in the standard documentation here, I see the following:

The master secret is expanded into a sequence of secure bytes, which
is then split to a client write MAC key, a server write MAC key, a
client write encryption key, and a server write encryption key.

To generate the key material, compute

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

until enough output has been generated. Then, the key_block is
partitioned as follows:


Correct me if I am wrong please, does this mean:

$ms$, $kc_{mac}$, $ks_{mac}$, $kc$, $ks$ = $kdf (ms, nonce_s, nonce_c)$ ??

My questions:

  1. Does that means the kdf generates "actually" 6 keys, but in fact they are 4 keys?

  2. Does that means, the Finished messages are encrypted with the MAC keys and the data are encrypted with another key?

  3. Is the client_write key different from the server_write key? shouldn't they generate a share secret? shouldn't the application data encrypted with share symmetric key? why does the standard make two keys?


1 Answer 1


1) Does that means the kdf generates "actually" 6 keys, but in fact they are 4 keys?

The KDF generates 6 values; of the 6, 4 of them can be considered "keys" (in the sense that they'll be used to key some cryptographical primitive) and 2 are not (an IV is typically not considered a "key", as exposing it does not yield a security weakness).

Also, some TLS transforms do not use all of the 6 values; the protocol handles that by making the length of the values they don't use to be 0 (so the same general structure applies). I mention this because you may run into this situation later on...

3) IS the client_write key different from the server_write key?

Yes, the client_write key is different from the server_write key. The client_write key is used to encrypt the traffic that is sent by the client to the server, while the server_write key is used to encrypt the traffic that is sent by the server to the client.

As for why they use two different keys for the different directions, well, the original SSL protocol had different keys in the two directions because it used RC4 as the encryption transform, which would have serious problems if you used the same key in the two directions. When we get to TLS 1.2, they maintained the same structure, in part because they still support RC4, in part because it also helps some transforms (e.g. GCM, which you could use the same key in both directions if you were careful with nonces, but it's easier not to have to worry about that), in part because using different keys for different purposes is just good practice, and in part because there was no real reason to change.

shouldn't they generate a share secret?

Actually, the shared secret (assuming you're using a DH-based transform) is computed much earlier, as the premaster secret. That's one of the inputs into the KDF, hence all the keys generated by TLS depend on it.

To answer your further questions:

Which key is the key used in the Finished MAC ?

The master secret; that's not any of the 6 traffic values (which are used to protect traffic between the two stations), but an intermediate value that is generated from the premaster secret, and in turn is used to generate the 6 traffic keys.

And, yes, it is a value that is shared between the client and the server (absent a man-in-the-middle attack).

But the standards talk about 6 keys, each party has its own key?

Again, only 4 of those values are "keys"; in any case, they are used to protect records that are exchanged between the client and the server; they too are also common between the two sides, with the understandard that the 'client->server' traffic will be protected by 3 of those values, and the 'server->client' traffic will be protected by the other 3. All these keys are symmetric, so for the system to work, both sides need to know their values.

If you really want to learn about TLS 1.2 from the source, you might try looking at rfc5246. This is not a description of TLS 1.2; it is the official definition, and hence cannot be wrong.

  • $\begingroup$ could you check my edit please and illustrate to me where is the master-key? they pre-master is the DHE share key (e.g. g^{xy}) but this is used as input to the kdf to produce the master secret? is the master secret one key or that each party has its own? is the master key used in the Finished MAC computation? which key(s) are used to encrypt the Finished messages? $\endgroup$ Aug 12, 2017 at 19:17
  • $\begingroup$ @poncho edited my post with a little more details. $\endgroup$ Aug 13, 2017 at 2:11
  • $\begingroup$ There are actually two (three?) steps: PMS is determined depending on selected key-exchange (agreement result for (EC)DH, wrapped value for RSA, sometimes other things for PSK SRP etc) and MS is computed as PRF(PMS,nonces), all per section 8.1; then working keys and IVs as needed for selected cipher+MAC are computed as PRF(MS,nonces) per section 6.3. For session resumption, the 6.3 part (only) is redone with new nonces. And the example of AES-GCM does 'run into this situation' because it uses one key (and an IV) in each direction but no separate MAC keys. $\endgroup$ Aug 13, 2017 at 6:01
  • $\begingroup$ @dave_thompson_085 Thanks a lot. Partially clarified but still: In the working keys that are specified in section 6.3, there is: client_write_MAC_key[SecurityParameters.mac_key_length] 1) does this refer to the key used to encrypt the Finished messages? or the key used inside the MAC computation, i.e.MAC(key,hash(handshake-messages))? which key should be in the MAC? 2) Are these computed at the same stage? i.e. reference to my Figure in the original post, generating master and working keys is done at one stage (i.e. after the KeyExchnage and before the client Finished)? .. $\endgroup$ Aug 13, 2017 at 7:14
  • 1
    $\begingroup$ ..are the generated at the same stage? need clarification. $\endgroup$ Aug 13, 2017 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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