Computing
How can two strangers agree on a secret in public?
Your browser and a web server that have never met settle on a secret key while anyone on the network may be copying every message they send. That sounds impossible. It works because some things are easy to do and very hard to undo.
To keep a conversation private, two machines scramble it with a key: a long secret number that both of them know and nobody else does. With a shared key, encryption is a solved problem. The hard part is getting the key there in the first place.
The obvious answer is to send it. But on the internet every message passes through routers, Wi-Fi access points and cables owned by other people. Assume someone, traditionally called Eve (the eavesdropper), sees every word that Alice and Bob exchange. If Alice sends the key, Eve has it too. If Alice encrypts the key first, she needs another key to do it, and we are back where we started.
It seems that a secret can never be created out of public messages alone. That intuition is wrong, and the way it fails is one of the great ideas of the twentieth century.
Mixing paint
Here is the trick with paint instead of numbers. Alice and Bob agree, in public, on a starting colour: yellow. Each then picks a secret colour and tells no one. Alice stirs her secret into a pot of yellow and posts the pot to Bob; Bob does the same and posts his to Alice. Eve sees both pots go by.
Now each adds their own secret colour again, to the pot they received. Alice's pot now holds yellow + Bob's secret + Alice's secret. Bob's holds yellow + Alice's secret + Bob's secret. Same ingredients, same amounts, so the same colour, and that colour is their shared secret.
- Alice ends with
- —
- Bob ends with
- —
- Eve’s mixture
- —
The analogy captures the one property that matters: mixing is easy, and unmixing is, for practical purposes, impossible. Eve holds a pot containing yellow and Alice's secret, but she cannot pull the secret back out.
It also breaks, in two places. First, a determined Eve with a colour meter could try to work out what was added to the yellow; real paint is not as one-way as we need. Second, paint cannot be copied exactly or sent down a wire. For the real thing we need an operation on numbers that is just as easy to do and just as hard to undo.
Arithmetic on a clock
That operation lives on a clock. On an ordinary clock, 9 o'clock plus 5 hours is 2 o'clock: you wrap around after 12. Mathematicians call this arithmetic modulo 12, and they do it on clocks of any size. We will use a clock with a prime number of hours, p (a prime has no divisors except 1 and itself), labelled 0 to p − 1.
Pick a starting number g, the base. Multiply it by itself again and again, and after each multiplication wrap around the clock. After x multiplications you have
gx mod p
read “g to the power x, modulo p”: the remainder when gx is divided by p. For example, with g = 5 and p = 23: 5, then 25 → 2, then 2 × 5 = 10, then 50 → 4, and so on.
- gx mod p
- —
- Hours g reaches
- —
Hours visited so far, for x = 1, 2, 3, …
Two things to notice. Going forwards is easy: each step is one multiplication and one remainder. And some bases are better than others. On the 23-hour clock, g = 5 visits every one of the 22 non-zero hours before repeating; such a base is called a generator. Try g = 2 instead: it visits only 11 hours, so there are only half as many places to hide.
Going backwards — given the hour, find x — is called the discrete logarithm problem. On a 23-hour clock you can solve it by trying all 22 exponents. On a clock whose number of hours has 600 digits, nobody knows how to solve it in any reasonable time. That gap is the one-way street we need.
The exchange, and Eve
Now replace the paint with numbers. Alice and Bob agree in public on a prime p and a generator g (the “yellow”). Alice picks a secret exponent a, and Bob a secret b. Then:
- Alice sends A = ga mod p. Bob sends B = gb mod p. These are the pots in the post.
- Alice computes Ba mod p. Bob computes Ab mod p.
Both get gab mod p, because raising g to the power a and then b is the same as doing it the other way round, and wrapping around the clock along the way doesn't change that. This is Diffie–Hellman key exchange.
Alice (private)
secret a =
sends A = ga mod p =
key = Ba mod p =
Public (Eve sees)
p = , g =
A = , B =
Bob (private)
secret b =
sends B = gb mod p =
key = Ab mod p =
- Eve’s tries
- 0
- Eve’s status
- waiting
With these tiny primes Eve always wins in a blink. The whole defence is in the size of p. Each extra binary digit (bit) doubles the number of hours on the clock, and so doubles the number of exponents Eve might have to try. Alice's work grows far more slowly: by squaring repeatedly (g, g2, g4, g8, …) she can reach any power with about two multiplications per bit.
- Alice: multiplications
- —
- Eve: tries (worst case)
- —
- Eve’s time at 109 tries/s
- —
Real attackers are cleverer than Eve. The best known method for this problem, the number field sieve, is enormously faster than trying every exponent, which is why real primes have 2,048 bits or more rather than 128. Measured against that attack, a 2,048-bit prime gives roughly the security of a 112-bit key (NIST's figure), about 5 × 1033 tries, not the 10616 that Figure 4 shows for brute force. In 2015 the “Logjam” researchers estimated that special-purpose hardware costing hundreds of millions of dollars could break a commonly shared 1,024-bit prime, a sum within reach of a national intelligence agency. But even the best known attack still grows faster than any fixed power of the number of bits, while Alice's effort stays modest. The gap widens as the primes grow.
What it doesn't do: tell you who is on the line
There is a hole in everything above. Alice assumed the number B came from Bob. Suppose Eve does more than listen: she sits in the middle, intercepts A, sends Bob her own number instead, and does the same in the other direction. Alice ends up sharing a key with Eve, Bob shares a different key with Eve, and Eve decrypts, reads and re-encrypts everything that passes. Neither notices. This is a man-in-the-middle attack.
Alice
sends A = 56 mod 23 = 8
receives
key =
On the wire
Bob
sends B = 515 mod 23 = 19
receives
key =
Key exchange on its own gives you a secret shared with whoever answered. To know
who that is, real protocols add authentication: in TLS, the protocol behind
https, the server signs its half of the exchange with a key vouched for by a
certificate, which your browser checks.
Who thought of it, and what runs today
Whitfield Diffie and Martin Hellman published the method in November 1976, in a paper called “New Directions in Cryptography”. Ralph Merkle had independently found a way to agree on a key in public (his “puzzles”, proposed as a student project in 1974 and published in 1978), and Hellman later suggested calling it Diffie–Hellman–Merkle key exchange. Unknown to all of them, three mathematicians at GCHQ, the British signals intelligence agency, had got there first: James Ellis showed in 1970 that such a thing was possible in principle, Clifford Cocks found a practical method in 1973 (essentially what became RSA), and Malcolm Williamson described the same exchange as Diffie and Hellman in a secret report in January 1974. It all stayed classified until December 1997.
Your browser today usually does the exchange not on a clock of numbers but on an elliptic curve, a different mathematical setting where the backwards problem is harder still, so keys can be much shorter. A very common choice, X25519 (RFC 7748, 2016), uses 32-byte keys. A large enough quantum computer, running Shor's algorithm, could solve both kinds of discrete logarithm; no such machine exists yet, but recorded traffic could be decrypted later. So since late 2024, Chrome and Firefox also run ML-KEM, a post-quantum method standardised by NIST as FIPS 203 in August 2024, side by side with X25519, and combine the two secrets.
What this model leaves out
- Authentication. As above, plain Diffie–Hellman does not tell you who you are talking to. Real handshakes sign the exchange and check certificates.
- Safe parameters. Our primes have at most 6 bits. Real ones have 2,048 bits or more and are chosen with care (for example “safe primes” p = 2q + 1, with q also prime), and each side checks the number it receives is valid; badly chosen groups have been broken.
- Better attacks. Figure 4 counts only brute force. The number field sieve and other methods are far faster, which is why real sizes are so large. Figure 4 also counts every multiplication as one step, although multiplying 2,048-bit numbers takes longer than multiplying small ones.
- Side channels. A real implementation can leak its secret through timing, power use or cache behaviour, even when the mathematics is sound. X25519 was designed to be easy to implement in constant time.
- Turning the number into keys. The shared number is not used directly. Real systems feed it, with the handshake transcript, through a key derivation function (TLS 1.3 uses HKDF) to produce the actual encryption keys.
- Paint. Our colours mix by a simple equal-parts rule on screen colours; real pigments are messier, and a careful chemist could partly unmix them.
Sources
- W. Diffie and M. E. Hellman, “New Directions in Cryptography”, IEEE Transactions on Information Theory 22(6), 644–654, November 1976; summarised in Wikipedia, “Diffie–Hellman key exchange”. The protocol, the paint analogy, the worked example p = 23, g = 5, a = 4, b = 3 → key 18 (reproduced exactly by Figure 3), Merkle's role and Hellman's 2002 naming suggestion.
- M. J. Williamson, “Non-Secret Encryption Using a Finite Field”, CESG report, 21 January 1974; see Wikipedia, “Malcolm J. Williamson”. GCHQ's earlier, secret discovery (Williamson, January 1974) and its declassification in 1997. Ellis's 1970 and Cocks's 1973 dates are from J. H. Ellis, “The History of Non-Secret Encryption” (CESG, 1987).
- A. Langley, M. Hamburg and S. Turner, RFC 7748, “Elliptic Curves for Security”, January 2016. X25519, its prime 2255 − 19 and 32-byte keys; design for constant-time implementation.
- NIST, FIPS 203, “Module-Lattice-Based Key-Encapsulation Mechanism Standard”, 13 August 2024. ML-KEM: what it is and that it is intended to resist quantum attacks.
- The Hacker News, “Google Chrome Switches to ML-KEM for Post-Quantum Cryptography Defense”, September 2024. Chrome combining ML-KEM-768 with X25519 in TLS by default (Chrome 131, November 2024). Firefox 132 on desktop, October 2024, from Cloudflare's post-quantum support table.
- E. Barker, NIST SP 800-57 Part 1 Rev. 5, “Recommendation for Key Management”, 2020, Table 2; D. Adrian et al., “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”, ACM CCS 2015 (weakdh.org). A 2,048-bit finite-field group is rated about 112 bits of security; Logjam's estimate of hundreds of millions of dollars of hardware to break one 1,024-bit prime.
Colophon
- Date
- 1 October 2026