0

I'm using this SSL handshake reference. It talks about the client generating a pre-master key and encrypting that with the server's public key. Then it sends that pre-master key securely to the server. Makes total sense.

My question is, though, hasn't symmetric encryption already been accomplished? The client and server both have and know the pre-master key and no other actor can. So if that's the case, then what is the point of the client and the server generating a shared secret key?

It seems like the shared secret is just another symmetric key.

And also, a related question: The client and server both generate the shared secret key, but they do this separately. Is the client shared secret identical to the server shared secret (I assume "yes", just wanted to clarify)?

Thomas Stringer
  • 211
  • 2
  • 7
  • That website is out of date and has outright errors. Early SSL/TLS often did use plain-RSA 'key' transport (encrypting the premaster secret under the server publickey) but it could also use ephemeral Diffie-Hellman (originally the classic/integer version, later ECDH also) which provide 'forward secrecy' and after Snowden, in fact right around the time that webpage was written, most of the world shifted pretty quickly to (EC)DHE and not plain-RSA. In 2018 (several years later) TLS 1.3 dropped plain-RSA entirely, and also greatly reduced the number of things set by the ciphersuite, ... – dave_thompson_085 Oct 29 '21 at 03:34
  • ... But even in 2015, and for decades before, the ciphersuite NEVER controlled client-authentication. And using a ciphersuite wasn't and isn't the only way of doing a quick negotiation; over the same period SSL/TLS used ciphersuite SSH used separate negotiation just as efficiently. About the only thing _right_ is that SSL/TLS combines asymmetric and symmetric cryptography. – dave_thompson_085 Oct 29 '21 at 03:37

0 Answers0