In the SSL handshake both the client and server generate their respective random numbers. The client then generates a pre master secret and encrypts it with the server's public key. However, why can't the client just generate the pre master secret and send that to the server? Why do we need a client and server random? Is it to contribute to the entropy in the master secret, or for uniformity with other key exchange algorithms such as DH?

up vote 23 down vote accepted

From The First Few Milliseconds of an HTTPS Connection:

The master secret is a function of the client and server randoms.

master_secret = PRF(pre_master_secret, 
                    "master secret", 
                    ClientHello.random + ServerHello.random)

Both the client and the server need to be able to calculate the master secret. Generating a pre-master secret on the client and just sending that to the server would mean the the client never gets to find out the master secret.

Why not just use the pre-master?

This would mean that the entire key generation routine was based on client generated values. If a Man-In-The-Middle attacker replayed the handshake, the same pre-master secret would be sent and then used for the connection. Having the server generate a random value (ServerHello.random) will mean that the MAC secret is different if the ClientHello.random is repeated, and therefore the MAC and encryption keys will be different, preventing any replay attack.

Useful when resuming a session

In TLS, the master secret is used with server and client random bytes in a PRF function to calculate a key block.

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

Then the key block is divided to provide six keys used for different operations :

  • 2 encryption keys
  • 2 MAC keys
  • 2 IV (when needed by encryption primitive)

When resuming a session, the same master key is used to generate key block. So use of client and server random bytes ensures that key block will be different in every handshake.

Is it to contribute to the entropy in the master secret...

Yes. It ensures both parties contribute to the master secret.

The master secret is the seed used to derive the subsequent keys used for bulk encryption and authentication.

... or for uniformity with other key exchange algorithms such as DH?

No. Diffie-Hellman requires both parties to contribute by selecting a random secret value a (or b), and then sending the other party the A=G^a (or B=G^b). Contributory behavior is baked into Diffie-Hellman.

There are other Key Agreement schemes. RSA is a Key Transport schemes, but it does not offer the opportunity for the server to contribute to the premaster secret. That is, there is no contributory behavior inherent to RSA key transport.

In the case of RSA key transport, the way to ensure both parties contribute to the master secret is:

master_secret = Transform(premaster_secret + client_random + server_random)

A practical problem the contributory behavior solves is, imagine an IoT device that has a broken or useless random number generator. The contributory behavior ensures the channel is [mostly] secure even when the client lacks randomness.

It is part of the Handshaking. it exposes the premaster secret but only to the server and client not to anyone in between. No one but the server can access the secret generated by the client due to no one but the server having the secret key to decrypt with.

Apparently my awnser is lacking Quoting @Raz here to make it a better awnser. (incorperated into my awnser above)

no the premaster secret is encrypted with the server's public key. The client and server ransoms are used with it (and other constants) to generate the Master key. Which is then used to generate sessions keys. Might want to read the answers for How Does SSL work for more details on the handshake

  • 4
    This is just wrong. The client and server randoms are sent in the clear. Anyone can see them in between. – RoraΖ May 16 '15 at 14:21
  • How its encrypted with the Servers secret key... Or my knowledge of the SSL exchange is lacking (always possible) – LvB May 16 '15 at 14:46
  • No the premaster secret is encrypted with the server's public key. The client and server ransoms are used with it (and other constants) to generate the Master key. Which is then used to generate sessions keys. Might want to read the answers for How Does SSL work for more details on the handshake. – RoraΖ May 16 '15 at 14:48
  • I thought thats what I put down in here... but ok – LvB May 16 '15 at 14:50
  • 1
    The OP is asking about the Client Random and Server Random values, not the pre-master secret. Which I see now is what you're referencing, but it is not the answer to the question. – RoraΖ May 16 '15 at 14:52

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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