🔐 Cryptography · Maths
📅 March 2026 ⏱ ~9 min read 🟡 Intermediate

How Diffie-Hellman Key Exchange Works

Alice and Bob have never met. They communicate over a channel that Eve can see in full. Yet after a brief exchange of numbers, Alice and Bob share a secret Eve cannot determine — even knowing every message they sent. This is Diffie-Hellman key exchange, the engine under HTTPS.

The Key Distribution Problem

Classical symmetric encryption (like AES) is fast and secure — but it requires both parties to know the same key. Before the internet, exchanging keys meant meeting in person, a diplomatic courier, or a physical token. For millions of web servers speaking to billions of browsers simultaneously, this is impossible.

In 1976, Whitfield Diffie and Martin Hellman published a landmark paper: "New Directions in Cryptography." Their protocol lets two parties derive an identical secret key by exchanging only public information — without ever transmitting the key itself. It solved a problem that had been considered unsolvable for millennia.

2015 NSA-classified discovery: Later declassified documents reveal that British GCHQ cryptographers Malcolm Williamson and James Ellis discovered the same concept in 1969–1973, but it was classified. Diffie and Hellman's independent re-discovery made it public.

The Paint-Mixing Analogy

The canonical way to understand DH is with paint colours. Mixing paints is easy; "unmixing" them is hard. This mirrors the one-way mathematical function at DH's core.

Public
Yellow (public g, p)
+
Alice's secret
Red (private key a)
=
Alice sends
Orange (public A)
Public
Yellow (public g, p)
+
Bob's secret
Blue (private key b)
=
Bob sends
Teal (public B)
Teal (B)
Alice receives
+
Red (a)
Her secret
=
Shared
Purple (shared secret!)
Orange (A)
Bob receives
+
Blue (b)
His secret
=
Shared
Purple (same secret!)

Eve sees yellow, orange, and teal — the public colours. Reconstructing the separate red and blue from the mixes is the "unmixing" problem. In maths, this corresponds to the discrete logarithm problem.

The Maths: Modular Exponentiation

The paint analogy has a precise mathematical version. Alice and Bob agree on two public numbers: a large prime p and a generator g (both can be published worldwide — everyone knows them).

Public parameters (known to everyone, including Eve): p = 23 (a large prime — in practice, 2048+ bits ≈ 617 decimal digits) g = 5 (a generator — a primitive root modulo p) Alice picks a private key: a = 6 (kept secret forever) Bob picks a private key: b = 15 (kept secret forever) Alice computes: A = gᵃ mod p = 5⁶ mod 23 = 15625 mod 23 = 8 → Alice sends A = 8 publicly Bob computes: B = gᵇ mod p = 5¹⁵ mod 23 = 30517578125 mod 23 = 19 → Bob sends B = 19 publicly Alice computes shared secret: s = Bᵃ mod p = 19⁶ mod 23 = 2 Bob computes shared secret: s = Aᵇ mod p = 8¹⁵ mod 23 = 2 Both arrive at s = 2 — without ever transmitting it!

The mathematical identity that makes this work:

(gᵃ)ᵇ mod p = (gᵇ)ᵃ mod p = gᵃᵇ mod p

Alice computes (gᵇ)ᵃ and Bob computes (gᵃ)ᵇ — they reach the same value because exponentiation over modular arithmetic is commutative.

Why It's Hard to Reverse

Eve knows p, g, A = gᵃ mod p, and B = gᵇ mod p. To crack the exchange, she needs to recover either a or b — to solve the equation:

Given g, p, and A: find a such that gᵃ ≡ A (mod p) This is the Discrete Logarithm Problem (DLP).

For integers with no "mod", this is trivial: if 5ᵃ = 3125, clearly a = 5. Under modular arithmetic, the pattern is destroyed — values "wrap around" in a way that appears chaotic. No algorithm is known that solves the DLP efficiently for large primes.

Scale matters: With the toy numbers above (p = 23), Eve could find a by trying all 23 possibilities in milliseconds. Real DH uses primes with 2048–4096 bits. The best known algorithm, the General Number Field Sieve, would require more computation than all the computers ever built running for millions of years.

Alice and Bob Step-by-Step

Step Alice Channel (Eve sees) Bob
1 — Agree params Knows p=23, g=5 p=23, g=5 published Knows p=23, g=5
2 — Private keys Picks a=6 (secret) Picks b=15 (secret)
3 — Public values Sends A=8 A=8, B=19 visible Sends B=19
4 — Shared secret s = 19⁶ mod 23 = 2 s=2 never transmitted s = 8¹⁵ mod 23 = 2
5 — Encryption Both use s=2 (in practice hashed/stretched) as the AES key for the session

The Man-in-the-Middle Problem

Plain Diffie-Hellman has one critical weakness: it does not provide authentication. If Eve intercepts the connection at the start, she can perform two separate DH exchanges — one with Alice pretending to be Bob, and one with Bob pretending to be Alice. Both "secure" channels actually run through Eve.

This is why real HTTPS pairs Diffie-Hellman with a certificate: a digital signature from a trusted Certificate Authority (CA) confirming that the server's public key really does belong to, say, bank.com and not an impersonator.

DH alone is not enough: without a way to verify who you are talking to, secrecy is useless. Always pair key agreement with authentication.

Elliptic-Curve Diffie-Hellman (ECDH)

Modern TLS almost always uses ECDH instead of classic DH. The same conceptual exchange happens, but instead of modular exponentiation on integers, it uses point multiplication on an elliptic curve: a smooth curve defined by y² = x³ + ax + b over a finite field.

The "hard problem" for ECDH is the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a point P and Q = k·P on the curve, find k. ECDLP is believed to be significantly harder than classical DLP, which means:

Diffie-Hellman in TLS/HTTPS

Every time you visit an https:// site, a TLS handshake runs Diffie-Hellman (or ECDH) in milliseconds. TLS 1.3 (2018) mandates only Diffie-Hellman-based cipher suites, dropping all others, because DH provides forward secrecy:

Forward secrecy: Each connection generates a fresh, ephemeral DH key pair. If an adversary records encrypted traffic today and later obtains the server's long-term private key, they still cannot decrypt the old sessions — the ephemeral DH keys were never stored anywhere. Classic RSA key exchange does not have this property.

Typical TLS 1.3 key exchange using X25519 (ECDH with Curve25519):

Client Hello → supported groups: x25519, secp256r1 … Server Hello → chosen: x25519 server public key Y_s = k_s · G Client sends Y_c = k_c · G Both compute secret = k_c · Y_s = k_s · Y_c = k_c · k_s · G Session keys derived via HKDF from secret + transcript hash

Post-Quantum Threat

Shor's Algorithm, running on a sufficiently large quantum computer, can solve both the integer factoring problem (RSA) and the discrete logarithm problem (DH/ECDH) in polynomial time — making both protocols insecure.

A cryptographically-relevant quantum computer does not yet exist (experts estimate 10–20 years away with current progress), but the threat is real enough that NIST standardised four post-quantum cryptographic algorithms in 2024, including CRYSTALS-Kyber for key encapsulation — a replacement for Diffie-Hellman based on lattice problems that are believed to resist quantum attacks.

Google, Apple, and Signal have already deployed hybrid post-quantum handshakes in their products, combining classical ECDH with a post-quantum algorithm.