I studied about SSL/TLS and learned that client and server must share keys below.

  • common key for encryption
  • common key for generating message authentication code

Then, in SSL/TLS, a client doesn't send these keys to server directly, but it sends pre master secret and generates keys from it. This is why?

  • 2
    $\begingroup$ I'm voting to close this question as off-topic because this is more of a IT security question, and it actually already has an answer there. $\endgroup$
    – Maarten Bodewes
    Apr 4, 2015 at 10:38
  • $\begingroup$ Thank you for your comment. I got an great answer in the page you provided. I tried to close the question but I couldn't find how to do it. $\endgroup$
    – moriteru
    Apr 4, 2015 at 12:12
  • 5
    $\begingroup$ @MaartenBodewes I disagree: this is not an IT security question, it's a protocol design question. Protocol design is cryptography. $\endgroup$ Apr 4, 2015 at 14:11
  • $\begingroup$ @Gilles OK, I can go along with that. But should we really create another answer just for this site? $\endgroup$
    – Maarten Bodewes
    Apr 6, 2015 at 1:15

1 Answer 1


The point of a premaster secret is to provide greater consistency between TLS cipher suites. While RSA cipher suites involve the client sending a random 48-byte premaster secret directly to the server, other suites do more complex things to generate the secret, and end up with a secret that might have some structure to it. For instance, (EC)DH suites use (elliptic curve) Diffie-Hellman to negotiate the secret; the output of this can be longer or shorter than 48 bytes, and it might potentially be poorly distributed (which could be bad). For PSKs, it's even worse - the premaster secret basically is the PSK. For various reasons, it's nice to have the master secret be some consistent format; it lets you separate the key-exchange side from the encryption side. Likewise, it's nice to have the master key be pseudorandom.

While you could require key exchange mechanisms to output the master secret directly meeting specific requirements, just about every key exchange system would do it the same way anyway (i.e. pass the negotiated value through the TLS PRF). Since most key exchange methods result in a shared secret that needs some transformation, and that transformation works well for basically every key exchange method, they just put it in the TLS spec for all methods to use.

  • $\begingroup$ Thank you for your great answer. I understand it clearly. $\endgroup$
    – moriteru
    Apr 6, 2015 at 1:43

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.