Diffie-Hellman key exchange
How two strangers agree on a shared secret over a public channel using nothing but a prime, a generator and one exponentiation each, and why the exchange alone cannot tell them who they are really talking to.
- Compute both public values and the shared secret given p, g, a and b, showing every step.
- Explain algebraically why Alice's and Bob's independent computations land on the same key.
- Trace a person-in-the-middle attack step by step and state what the attacker ends up holding.
- Explain why digital signatures close the gap that makes the attack possible.
20 min read
Intuition
Symmetric encryption needs both sides to already hold the same key. RSA solves that by letting anyone encrypt with a public key that only one person can decrypt, but that means committing to a whole public-key infrastructure just to move a session key. Diffie-Hellman does something narrower and, for this one job, simpler: two people who share nothing in advance can still walk away from a conversation an eavesdropper heard in full, holding a secret number the eavesdropper cannot compute.
Mechanism
Alice and Bob start from two values that are public from the beginning: a prime , and , a primitive root (generator) of . Anyone, including an attacker, may know both.
| Alice | Bob | |
|---|---|---|
| 1. Pick a private value | random | random |
| 2. Compute a public value | ||
| 3. Send it | sends to Bob | sends to Alice |
| 4. Compute the shared secret |
and never leave their owner. Only , , and cross the channel, and all four are things an eavesdropper is allowed to see without threatening the outcome.
Why the two computations agree. Substitute what and actually are:
Since , both sides land on the identical value , computed two different ways, without either exponent ever being transmitted.
Why an eavesdropper is stuck. Someone who only watches the exchange knows , , and , but not or . Recovering either one from its public value (finding such that ) is the discrete logarithm problem from the earlier page on trapdoor functions, believed infeasible for a large enough . Diffie-Hellman’s security is that problem, applied directly: a passive listener is locked out.
Diffie–Hellman key exchange
Alice and Bob agree on p and g in public, each picks a private exponent, and each publishes gᵃ mod p or gᵇ mod p. Both then raise the other's public value to their own private exponent and land on the same K — because (gᵃ)ᵇ ≡ (gᵇ)ᵃ ≡ gᵃᵇ (mod p) — without either exponent ever crossing the wire. Security rests on the discrete logarithm problem: recovering a from gᵃ mod p is believed infeasible for a large enough prime p.
Worked example
Answerp=23, g=5, a=6, b=15: Alice sends X=8, Bob sends Y=19, and both independently compute the shared secret K=2.
- Public parameters: , .
- Alice picks . Bob picks . Neither value is sent.
Alice computes by repeated squaring: , , . , so .
Bob computes . Continuing the same powers: . , so : , then , then . So .
- Alice sends to Bob. Bob sends to Alice. Both values cross the open channel.
Alice computes . , . .
Bob computes . , , . , so : , then , then .
- Both sides reach , computed independently, with and never sent.
Threat
Person-in-the-middle. The exchange authenticates nobody: a public value is accepted regardless of who actually sent it. An active attacker sitting between Alice and Bob intercepts both public values and runs two independent Diffie-Hellman exchanges: one posing as Bob to Alice, one posing as Alice to Bob. Each exchange completes normally and produces a valid shared key, so the attacker ends up holding two working keys: one matching what Alice thinks she shares with Bob, one matching what Bob thinks he shares with Alice, while Alice and Bob each believe they are talking directly to the other.
Diffie–Hellman under a person-in-the-middle attack
Passive eavesdropping cannot recover K without solving the discrete logarithm problem, but Diffie-Hellman on its own authenticates no one. Mallory runs two separate exchanges — one impersonating Bob to Alice, one impersonating Alice to Bob — and ends up holding both resulting keys, invisibly relaying (and reading) every message. The fix is to sign each side's public value, so a substituted Xₘ or Yₘ fails verification.
Worked example
AnswerWith Eve using private value 9 against Alice (a=6) and Bob (b=15), Alice ends up sharing key 9 with Eve and Bob ends up sharing key 10 with Eve: two different keys, and neither notices.
Same , , Alice’s , Bob’s . Eve intercepts the exchange and uses her own private value in both directions.
Eve and Alice. Alice still computes her real (as above) and sends it, straight to Eve, who intercepts it. Eve computes a public value using her own private : . Continuing the powers from the previous derivation: . Eve sends to Alice, posing as Bob’s .
Alice computes what she believes is the shared secret: . , . . Alice’s key is .
Eve computes the same leg from her side: . From the earlier powers of : , so . Eve gets too. This leg of the exchange is internally consistent, exactly like a real one.
Eve and Bob. Eve reuses her public value (still ) and sends it to Bob, posing as Alice’s . Bob still computes his real (as above) and sends it, straight to Eve.
Bob computes what he believes is the shared secret: . Continuing from : , , . Bob’s key is .
Eve computes the same leg from her side: . Continuing from by repeated multiplication: , , , , , , , , . Eve gets too.
Eve now holds two working keys: , shared with Alice, and , shared with Bob. Alice’s key () and Bob’s key () do not match each other. Neither Alice nor Bob can tell, because each of them completed a valid-looking exchange and reached a key that is genuinely shared, just with Eve, not with each other.
Control
Digital signatures. Have each party sign their own public value with a private signing key established out of band, and have the other party verify that signature before trusting the value. Eve can still intercept and , but she cannot produce a signature over her own substituted public value that verifies against Alice’s or Bob’s real signing key: she does not hold either one. The Diffie-Hellman exchange itself is unchanged; what changes is that a forged public value now fails a check before it is ever used to compute a key.
Exam detail
The exam pairs this attack with its fix as a single question shape: name the vulnerability (no authentication of the public values), describe the attack (two independent exchanges, two different keys, both parties deceived), and name the control (signed public values). Diffie-Hellman is secure against a passive eavesdropper because of the discrete logarithm problem; it is not secure against an active attacker on its own, because the protocol as given has no way to check who sent a public value.
Pitfall
Do not describe the person-in-the-middle attack as “breaking” the discrete logarithm problem. Eve never computes a private exponent from a public value. She does not need to, because she generates her own valid key pair and runs two ordinary exchanges. The failure is entirely about missing authentication, not about the underlying maths giving way.
Recall
Alice and Bob complete a Diffie-Hellman exchange and both compute the same K. Does this prove they were talking to each other, and not to an attacker in the middle?
No. Each side only proves that some exchange completed correctly on their end. The maths guarantees agreement with whoever sent the public value they received, not that the sender was who they think it was. Diffie-Hellman on its own authenticates nobody, which is exactly what makes the person-in-the-middle attack possible.
Source
Week 5 notes PDF