# DHE_RSA master secret computation?

When using DHE_RSA, the prime $p$, the generator $g$ and the public keys $A$ and $B$ are transmitted in plain text. If I know the private key of the server $a$, I can calculate $k=B^a\ mod\ p$ to receive the pre master secret (correct me if I'm wrong). According to RFC 5246, this pre master secret is then combined with some random values sent in the server and client hello messages and hashed to receive the master secret.

Now, my question is how this calculation of the master secret is done in practice (which hash function is used, how are the parameters combined,...).

It's performed using the PRF, as indicated by the RFC specifying the TLS 1.2 specification you pointed to. The PRF is identified by the cipher suite - commonly as last part of the cipher suite string.

How the PRF works is specified by section 5 of the TLS 1.2 specification:

In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudorandom function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.

And the specification then says:

 master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];


followed by:

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


after which the output key_block is split into the session keys required.

So the entire spec relies on the PRF, which relies on the iterated P_hash, which relies on HMAC_hash which relies, finally, on a secure hash such as SHA-256. Otherwise it is just concatenation and splits of octet string (also known as byte arrays). I won't copy the algorithms here, they are well described in the TLS specification.

As it doesn't rely on any other cryptographic primitives the cipher suite string simply lists the hash function used as configuration parameter for the PRF, for instance SHA-1 in TLS_RSA_WITH_AES_128_CBC_SHA and of course SHA-256 in TLS_RSA_WITH_AES_128_CBC_SHA256, both from appendix C of the specification.

Note that the DH handling of TLS 1.2 is a bit strange in the fact that it uses the minimal size encoding of the DH result as pre_master_secret. Generally the output of DH Is considered static, and of the same size as the prime field (i.e. 1024 bit for 1024 bit DH). So you should not left-pad with zeros for TLS 1.2. This has been fixed in TLS 1.3 draft specification (to be precise after I mentioned it in the mailing list, in draft 13).

Note that the generation of keys using the PRF is generally known as (key based) key derivation. The PRF is therefore used as TLS-specific Key Based Key Derivation Function or KBKDF.

• To add a bit: earlier TLS versions (1.1 and 1.0) used a similar but slightly different PRF, and SSL 3 used a more different KDF (not labelled PRF), but all share the premaster-KDF-master-KDF-working structure (which 1.3 changes substantially) except the obsolete-since-1.1 (and rightly so) 'export' suites added another KDF pass at the end. – dave_thompson_085 Nov 16 '17 at 22:35