Key Exchange (key establishment, key agreement)

Key exchange is how two parties end up holding the same secret without an eavesdropper learning it. TLS has used several methods: RSA key transport, where the client encrypts a random premaster secret with the server's RSA public key (TLS 1.2 and earlier only); ephemeral Diffie-Hellman key agreement, DHE or ECDHE; pre-shared keys; and, most recently, hybrid schemes that add a post-quantum KEM. In TLS 1.3 the client lists its groups in supported_groups and sends key_share values for its likely choices; if the server wants a group the client did not send, it replies with a HelloRetryRequest, costing an extra round trip.

Why it matters

The key exchange decides whether a connection has forward secrecy and whether it resists future quantum computers. With RSA key transport, anyone who later obtains the server's private key can decrypt every recorded session. The "harvest now, decrypt later" threat is why browsers moved to hybrid key exchange such as X25519MLKEM768 before post-quantum certificates exist.

Example

Common key exchange methods in TLS:

Method              Protocols            Forward secrecy
RSA key transport   TLS 1.2 and older    No
DHE / ECDHE         TLS 1.2, TLS 1.3     Yes
PSK only            TLS 1.2, TLS 1.3     No
PSK with (EC)DHE    TLS 1.2, TLS 1.3     Yes
X25519MLKEM768      TLS 1.3              Yes, plus post-quantum

Common misconceptions

• "Key exchange and authentication are the same step." Key exchange establishes the secret; signatures from the certificate key authenticate the server. RSA key transport merged the two, which is one reason TLS 1.3 dropped it.
• "The cipher suite name always shows the key exchange." That is true in TLS 1.2, but TLS 1.3 negotiates the group separately.
• "A larger RSA certificate key strengthens the key exchange." With ECDHE the certificate key only signs; the exchange's strength depends on the group.