Cryptography, before and after Shor · Topic 04 of 10 · Public keys

How two strangers agree on a secret

How can a secret be made in public, in front of a listener?

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08
  9. 09
  10. 10
About this section: Public keys

Public-key cryptography is what lets strangers talk safely, and it is the half a quantum computer breaks. These topics show how each lock works and what it rests on, using numbers small enough to follow, so that topic 07 can say exactly what Shor's algorithm does to them.

See it

Public, shouted across the room: p = 23, g = 5 Alice secret a = 6 A = 56 mod 23 = 8 196 mod 23 = 2 Bob secret b = 15 B = 515 mod 23 = 19 815 mod 23 = 2 A = 8 → ← B = 19 Shared secret: 2. Eve saw 23, 5, 8 and 19, never 6 or 15. With 22 possible exponents she can just try them all. With a 256-bit group she cannot.
Each side computes the same number by a different route. Alice raises Bob's public value to her secret power, Bob raises Alice's to his, and both equal 56×15 mod 23 = 2. Anyone watching holds the two public values and nothing that links them to the answer except a search.

The intuition

Until 1976, in public, every cipher needed the two parties to share a secret key in advance, which meant meeting or sending a courier. Whitfield Diffie and Martin Hellman's paper “New Directions in Cryptography” showed that two people who have never met can build a shared secret in front of a listener, using one idea: some operations are easy to do and very hard to undo.

The easy direction here is exponentiation in a clock-like number system, repeated multiplication with the answer wrapped around a prime p. Computing 56 mod 23 takes a few multiplications. Going back, given 8, to find the exponent that produced it is the discrete logarithm problem, and for a well-chosen large group nobody knows a fast way to do it on an ordinary computer. Each person mixes a private exponent into the public base and sends the result. The shared secret is then each side's own exponent applied to the other's result.

One thing the exchange does not do is tell you who you are talking to. Someone sitting in the middle can run one exchange with Alice and another with Bob and relay everything. Proving identity is the job of signatures, which is topic 06. Today the same idea runs on elliptic curves, where the group is a set of curve points and the arithmetic is faster and the keys shorter: the X25519 exchange sends only 32 bytes each way.

The mathematics

Why both sides agree. Work in the integers mod a prime p with a base g. Alice picks a and sends A = ga mod p; Bob picks b and sends B = gb mod p. Then

Ba = (gb)a = gab = (ga)b = Ab (mod p)

With p = 23, g = 5, a = 6, b = 15 the numbers are A = 8, B = 19 and the shared value 2 on both sides. The base 5 is a generator mod 23: its powers 5, 2, 10, 4, 20, 8, … run through all 22 nonzero residues before repeating, which is what makes every secret exponent give a different public value.

The hard problem. The attacker holds g, p, A and B and wants gab. The direct route is the discrete logarithm: find a with ga = A. In the toy, trying all 22 exponents finds a = 6 at once, and then 196 mod 23 = 2. A real group has about 2256 elements, and the best known classical attacks on well-chosen groups cost about the square root of the group size, so a 256-bit curve gives about 128 bits of security. Finite-field versions need much larger numbers: NIST rates a 2048-bit modulus at about 112 bits and 3072 bits at 128, because index-calculus methods run faster than square-root search there.

That is where Shor's algorithm will bite, in topic 07: the discrete logarithm is a period-finding problem, and a quantum computer is good at periods.

Try it: the exchange, and the eavesdropper

Pick a size, change the two secret numbers, and see both sides reach the same value. Then let the eavesdropper try every exponent. At 23 it takes a few steps; at 10,007 it is still instant. The point is the step count: it grows with the prime, and real groups are astronomically larger.

Where it actually runs

Every TLS 1.3 connection The handshake in your browser does an ephemeral elliptic-curve Diffie-Hellman exchange on the X25519 curve, increasingly combined with ML-KEM in the hybrid of topic 10, a fresh pair of exponents per connection. Messaging apps and SSH do the same. This exchange, not the certificate, is what protects the traffic, and it is the part an attacker who records today can attack later.

Why that matters For most signatures, such as a handshake, the forgery has to happen while it is being checked, so it needs a machine that exists in 2026; the exceptions are keys that stay trusted for decades (topic 06). A Diffie-Hellman exchange recorded in 2026 can be attacked by a machine built in 2036, because the recording is still there. That asymmetry is the whole urgency of the migration, and topic 06 and topic 10 come back to it.