Public Keys

Chapter 2 established the hybrid model: use asymmetric crypto to agree on a shared symmetric key, then switch to fast symmetric encryption. This chapter answers the obvious follow-up — how exactly do the two parties agree on that key over a network an attacker is watching? There are two historical approaches, and the difference between them turns out to matter enormously for security.

Approach 1: RSA Key Transport (the old way)

The original TLS method used RSA key transport. The logic is simple:

1. The server has an RSA key pair; its public key is in its certificate (Chapter 4).
2. The client invents a random secret (the "pre-master secret"), encrypts it with the server's public key, and sends it.
3. Only the server's private key can decrypt it, so now both sides share that secret — from which the symmetric key is derived.

It works and it's easy to picture: the client effectively puts the secret in a box only the server can open. But it has a serious, subtle weakness that took the industry years to fully act on.

Approach 2: Diffie–Hellman Key Exchange (the modern way)

Diffie–Hellman (DH) solves the problem differently — and almost magically. It lets two parties derive a shared secret by exchanging only public values, such that an eavesdropper who sees everything sent still cannot compute the secret. The classic intuition is mixing paint:

The shared secret (brown) is never transmitted — each side computes it locally by combining their own private value with the other's public value. The "un-mixing is hard" property is, in real DH, the difficulty of certain mathematical problems (discrete logarithms). Critically, the secret was never put in a box tied to a long-lived key — it emerged from values that can be thrown away after the session.

Ephemeral Diffie–Hellman = Forward Secrecy

The security payoff comes when the DH private values are ephemeral — freshly generated for each session and discarded immediately afterward. This is signalled by an E in cipher names: DHE (ephemeral DH) and ECDHE (the elliptic-curve, faster variant used almost universally today).

But Wait — Where Does Authentication Fit?

Plain Diffie–Hellman has a gap: it establishes a shared secret with somebody, but it doesn't prove who. An active man-in-the-middle could run separate DH exchanges with each side and sit in the middle. DH alone gives confidentiality, not authentication — exactly the Chapter 1 warning that encryption without authentication is a private chat with a possible impostor.

TLS closes the gap by combining DH with a signature: the server signs its DH public value with the long-term private key from its certificate. So the two asymmetric tools play distinct roles, and it's worth keeping them separate in your mind:

This is a key clarification: in modern TLS the certificate's long-term key is used to sign (authenticate), not to encrypt the session secret. The session secret comes from ephemeral DH. That separation is precisely what delivers both authentication and forward secrecy at once — the old RSA-transport method conflated the two into one key and lost forward secrecy as a result.

RSA Transport vs Ephemeral DH — Side by Side

The progression is the whole point of this chapter: TLS 1.2 supported both, and TLS 1.3 (Chapter 7) dropped RSA key transport altogether, making forward secrecy mandatory. Every modern HTTPS connection you make uses ephemeral elliptic-curve Diffie–Hellman (ECDHE) for key agreement, authenticated by a certificate signature. The next chapter examines that certificate itself.

Hands-On Exercises