Key exchange and forward secrecy

Both sides need the same symmetric key, but everything they send can be observed. Diffie–Hellman solves this: each side picks a private value, sends a corresponding public value, and combines its own private value with the other's public value. Both arrive at the same shared secret — and an observer, who sees only the public values, cannot compute it.

Real implementations use elliptic curves (ECDHE) or finite-field groups (DHE). The mathematics differs; the shape of the exchange is the same.

If the key-exchange values are fresh for every connection, the resulting session keys are never derived from the server's long-term private key. That property is forward secrecy: later compromise of the server's certificate key does not decrypt earlier recorded traffic.

TLS 1.3 uses a small set of named groups: X25519 is the modern default, with P-256 and P-384 for compatibility. Servers usually enable all three and let the client's preference decide.

• Prefer X25519: fast, constant-time friendly, widely implemented
• Keep P-256 for older clients and for environments with FIPS-oriented requirements
• Session ticket encryption keys are secrets too: rotate them, and prefer AES-256-GCM or ChaCha20-Poly1305 ticket protection

Forward secrecy is the reason a stolen server key today does not automatically mean all past traffic is readable tomorrow. It is also the reason protocol engineers removed static RSA in TLS 1.3 rather than making it optional.

For an operator the practical check is simple: inspect the negotiated cipher suite. If it names ECDHE (or TLS 1.3 suites, which always do), forward secrecy is in place.