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?
The master secret is a function of the client and server randoms.
master_secret = PRF(pre_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,
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
b), and then sending the other party the
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