Basis Lab

Answers · The network and the web

How can two computers agree on a secret key when anyone can listen?

In shortEach computer sends a scrambled number made from a private number; the shared key is made by scrambling the other computer's number with one's own private number, and a listener cannot unscramble it.

Two computers agree a key by sending each other a scrambled value and never sending the private number that went into it. Each then combines the other side's scrambled value with its own private number, and both arrive at the same shared key that a listener recording every message cannot reconstruct.

The public starting values are a prime, called the modulus, and a base. Call the modulus pp and the base gg. One side chooses a private exponent aa, computes ga mod pg^a \bmod p and sends it. The other chooses a private exponent bb, computes gb mod pg^b \bmod p and sends it. The first side raises what it received to aa, the second raises what it received to bb, and both get the same number because the two exponentiations commute.

s=(ga)b mod p=gab mod p=(gb)a mod p.s=(g^a)^b \bmod p = g^{ab}\bmod p = (g^b)^a \bmod p.

Worked with numbers small enough to check

The public values are p=23p=23 and g=5g=5. The first side picks a=6a=6. It computes 56=156255^6=15625, and 15625=23⋅679+815625=23\cdot 679+8, so it sends 88. The second side picks b=15b=15. It computes 515=305175781255^{15}=30517578125, and 30517578125=23⋅1326851222+1930517578125=23\cdot 1326851222+19, so it sends 1919.

The first side receives 1919 and computes 196 mod 2319^6 \bmod 23. By repeated squaring, 192=361=23⋅15+1619^2=361=23\cdot 15+16, 194=162=256=23⋅11+319^4=16^2=256=23\cdot 11+3, and 196=194⋅192=3⋅16=48=23⋅2+219^6=19^4\cdot 19^2=3\cdot 16=48=23\cdot 2+2. The second side receives 88 and computes 815 mod 238^{15}\bmod 23. Here 82=64=23⋅2+188^2=64=23\cdot 2+18, 84=182=324=23⋅14+28^4=18^2=324=23\cdot 14+2, 88=22=48^8=2^2=4, so 815=88⋅84⋅82⋅8=4⋅2⋅18⋅8=1152=23⋅50+28^{15}=8^8\cdot 8^4\cdot 8^2\cdot 8=4\cdot 2\cdot 18\cdot 8=1152=23\cdot 50+2. Both hold 22.

FIG 1
valuefirst sidesecond sidesent on the wirelistener
p = 23yesyesyesyes
g = 5yesyesyesyes
a = 6yesnonono
b = 15noyesnono
g^a = 8yesyesyesyes
g^b = 19yesyesyesyes
s = 2yesyesnono

The natural guess, and why it fails

The natural guess is that the listener, seeing 88 and 1919, can simply combine them. It cannot. Multiplying them gives 8⋅19=152=23⋅6+148\cdot 19=152=23\cdot 6+14, and 1414 is not the key. Raising 88 to the 1919th power is not the same as raising 88 to the 1515th power; only the second is what the second side did. To reach 22, the listener needs either 66 or 1515. Recovering 1515 from 515 mod 235^{15}\bmod 23 means trying exponents until one produces 1919. With p=23p=23 there are only 2222 nonzero exponents to try, and the listener can do that by hand. That is exactly the weakness the real sizes are chosen to remove: the same search is still the only known route, but the number of candidates is made far too large to run.

Recovering an exponent from ga mod pg^a \bmod p is the discrete logarithm problem. No fast method is known at the sizes used, but nobody has proved that no fast method exists. The security is an assumption, not a theorem. If someone found a fast method, the listener could recover aa or bb from the published values and compute gab mod pg^{ab}\bmod p exactly as the two sides do. The method is used because it has survived sustained attack, not because it has been proved safe.

Where it stops being enough

Two conditions matter. The modulus must be large enough that the search is out of reach; a modulus that is too small makes the listener's job a finite computation, as it was with p=23p=23. Reusing one modulus across many conversations is also dangerous, because the expensive part of the attack depends on the modulus and not on the particular pair of private exponents, so an attacker can precompute once and reuse the result.

Separately, this exchange gives secrecy against a listener who only records. It gives nothing against an attacker who can alter messages, because that attacker can intercept both public values, substitute its own, and run two separate exchanges, one with each side. Both sides then share a key with the attacker rather than with each other, and the arithmetic is perfectly valid. Authentication, not more arithmetic, is what closes that gap.

Worth keeping

  • Two parties can agree a shared key by publishing values derived from private exponents and combining the other published value with one's own exponent modulo a public prime.
  • An eavesdropper who records the published values cannot compute the key without solving the discrete logarithm problem, for which no fast method is known.
  • Seeing the public numbers is not enough to compute the key, because the private exponents never cross the wire.

Where this goes next

This question is one step of How a Message Stays Private, a course that works through its subject from the beginning. The page that teaches this part of it is Agreeing a Secret in Public, and it reads the whole way through whether or not you have an account.

What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.

Read that pageThe whole course

Other questions people ask about this

  1. Why does the TLS handshake take so many round trips before any data is sent?It is not one key exchange. The handshake agrees a secret, proves the server's identity and checks for tampering, and modern TLS fits those into one round trip; a fresh connection still needs three before the page starts.
  2. If a website has HTTPS, can someone on the same Wi-Fi read my password?No. HTTPS encrypts the form contents and cookies, so someone on the same Wi-Fi cannot read the password itself; they can still see the site, timing and packet sizes.
  3. How does a man-in-the-middle attack still work if the key exchange is secure?A key exchange proves only that you share a secret with whoever answered. An attacker on the path answers you themselves and opens a second exchange to the real server, so both halves look secure.
  4. Does HTTPS hide the domain name of the site I'm visiting from my ISP?Usually not: the site's name is sent in readable form twice, once when your computer looks up its address and once when the secure connection opens.
  5. Where should a session ID be stored so JavaScript can't read it?Store it in an HttpOnly cookie set by the server; that is the only browser storage JavaScript running on the page cannot read.
  6. What does it mean for an API method to be safe?A safe method is one that changes nothing on the server when it is called, so a caller may repeat it freely and a cache or a crawler may use it without anything being altered.

Read alongside