Key agreement

Key agreement processing is a critical component of TLS negotiation because it allows the client and server to pick the symmetric key that is used to encrypt the remainder of the communication, but without letting anyone else know what that key is.

There are a several different key agreement algorithms, but the most common ones use RSA or variants on Diffie-Hellman.

In RSA key exchange, the client generates some random data, encrypts it using the server’s public key, and provides that encrypted data to the server. The server uses its private key to decrypt it and get the random data that the client originally generated. Both the client and the server then derive the encryption key from that random data.

In Diffie-Hellman (DH) key exchange, the client and server publicly agree on a pair of mathematically linked numbers, and then each chooses its own secret value. Through a special computation, they come up with a key that is only known to someone who knows one of the secret values. There are a few different variants of the Diffie-Hellman algorithm that are used in key exchange, but ECDHE and DHE are the recommended versions because they use ephemeral keys without any relation to the server’s certificate, and of the two, ECDHE is preferred because it is faster and can use smaller keys without compromising security.

If possible, you should prefer ECHDE over DHE, and either of those over RSA. The Diffie-Hellman algorithms provide a substantial benefit over RSA in the form of forward secrecy. Because RSA key exchange uses the server certificate’s public key to encrypt data used to generate the symmetric key, if that certificate’s private key is ever compromised, then the encryption can be broken. This includes not only communication on new TLS connections, but also any data that might have been captured in the past. On the other hand, the use of ephemeral keys in ECDHE and DHE ensure that even if the certificate’s private key is compromised, any encrypted communication is still indecipherable to anyone but the client and server although anyone with the private key could still pretend to be the legitimate server.