# How key materials are generated in SSL V3 from master secret

The generation of key materials is given by

key_block =
MD5(master_secret + SHA('A' + master_secret + ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA('BB' + master_secret + ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA('CCC' + master_secret + ServerHello.random +
ClientHello.random)) + [...];


The document says, it is done until "enough output has been generated". I think the "+" refers to append the data generated.

We need:

• client write mac secret
• server write mac secret
• client write key
• server write key
• client write IV
• server write IV

So these are generated by taking appropriate number of bits from the generated hash?

I couldn't understand why the document says "enough output has been generated". Any way we need the 5 parts from the master key.

-

You can use TLS 1.0 as guidance: it is the direct successor of SSL 3.0, so many things are quite similar, and in some respects TLS 1.0 is a bit clearer. In section 6.3 you will find the key generation process, with the exact sentence:

To generate the key material, compute [...] until enough output has been generated. Then the key_block is partitioned as follows:

the important word being "partitioned".

For instance, if you are using 3DES as symmetric cipher and SHA-1 for the MAC, the "write keys" are 24-byte long each, the IV are 8-byte long each, and the MAC keys are 20-byte long each. So, a total of 104 bytes. The key generation function repeatedly invokes SHA-1 and MD5 on various elements; each round produces 16 additional bytes (that's the output size of MD5). You need 104 bytes, hence, you will need 7 rounds.

At the first round, you call SHA-1 over the concatenation of 'A' (a single byte of value 65), the master secret, the server random and the client random, in that order ('+' indeed denotes concatenation). This SHA-1 invocation yields 20 bytes. The concatenation of the master secret and the SHA-1 output is then hashed with MD5, which yields 16 bytes. These are the first 16 bytes of the key block.

For the second round, the processing is identical except that you use 'BB' instead of 'A' (two bytes of value 66 each). This produces the next 16 bytes of the key block.

You continue like this. Ultimately, you can potentially do 26 rounds (up to 'ZZZ...Z'; the SSL 3.0 specification does not define how to go beyond that). This would yield a total of 26*16 = 416 bytes. But if you need only the first 104 bytes, there is no need to compute the whole 26 rounds; just compute enough rounds to get the number of bytes you need.

Once you have your key block (104 bytes with 3DES and SHA-1), you split it into the needed key elements. The first 20 bytes go to the client write MAC key, the next 20 bytes for the server write MAC key, then the next 24 bytes for the client write key, and so on.

-
The TLS 1.0 documentation says The cipher spec which is defined in this document which requires the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of 104 bytes of key material. How they arrived at the key size of 24 byte for 3DES. A little search on net gives 3DES key size as 168, 112 or 56 bits  – user5507 Nov 9 '11 at 1:03
@user5507: the 3DES specification says that the key is a 192-bit words (three 64-bit DES keys). If you follow the specification, you can see that 24 of these bits are totally ignored by the algorithm, so the effective key size (with regards to exhaustive key search) is 168 bits; but the standard key must still be an array of 24 bytes. The "ignored" bits were supposed to be parity control bits (one parity bit for every seven "used" key bits) but nobody bothers setting or controlling them. – Thomas Pornin Nov 9 '11 at 12:08
@ThomasPornin well, except for e.g. the HSM's we use at my work, they check DES parity all right. According to ECRYPT II the strength of the 3DES keys is: For three-key 3DES, the attack complexity can be reduced down to 2112 operations (or even down towards 2^100 under certain attack models), whereas for two-key 3DES it reduces from 2^112 down to 2^(120−t) operations if the attacker has access to 2t plaintext/ciphertext pairs (t > 8) using the same key. – Maarten Bodewes Feb 27 '12 at 20:29
@ThomasPornin Do you have any document that mention the keys' length (write-mac-key, write-key, write-iv) for all the ciphersuites ? – vantrung -cuncon Nov 7 '13 at 4:35
@vantrung-cuncon: it is in the standard, appendix C; see also the previous versions: TLS 1.0 and TLS 1.1. – Thomas Pornin Nov 7 '13 at 12:05
   key_block =
MD5(master_secret + SHA('A' + master_secret + ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA('BB' + master_secret + ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA('CCC' + master_secret + ServerHello.random +
ClientHello.random)) + [...];


The document says, it is done until "enough output has been generated".

"[E]nough output has been generated" means that you have to continue this process until the key length is equal to the block length. For example, if the block length is 512 bits, then the function

    MD5(master_secret + SHA('A' + master_secret + ServerHello.random +
ClientHello.random))


needs to be repeated four times, because the output of MD5 is 128 bits long, and 4 × 128 = 512.

And + indicates concatenation.

-
What block length are you here referring to? – Paŭlo Ebermann Feb 27 '12 at 8:58