Try It Yourself: Watch an SSH Key Exchange Happen
Diffie-Hellman key exchange clicks once you watch two people agree on a secret number live, while a third person only ever sees the numbers travelling between them. Play all three roles yourself in an interactive demo.
The Hook
You have read about Diffie-Hellman key exchange. You have seen the formulas. But watching two people agree on a secret number, live, while a third person only ever sees the numbers travelling between them — that is where it actually clicks. This post walks through the idea in four steps, and each step is something you can run yourself, right here in the page.
The Problem, In One Line
Alice and Bob want to agree on a secret number. An eavesdropper can see every message they send each other. By the end of this page, Alice and Bob will share a secret the eavesdropper cannot work out, even after watching the entire conversation.
This is exactly what happens every time you run ssh user@server. Your laptop and the remote server are Alice and Bob. Anyone on the network path between you is the eavesdropper.
Try It Yourself
Play all three roles yourself, or better, grab two friends and let them each own a secret. Step 1 picks the numbers everyone can see. Step 2 is where Alice and Bob each enter a private number that never appears on screen. Step 3 shows you exactly what the eavesdropper gets to see — nothing more. Step 4 reveals that Alice and Bob landed on the same secret anyway.
Alice and Bob want to agree on a secret number. An eavesdropper watches every number they send each other, but should never be able to work out the secret they land on.
Pick a prime and a base. These two numbers are public — the eavesdropper can see them too, and that is fine.
Walking Through What Just Happened
Step 1 — the public numbers. You picked a prime p and a base g. The tool checks p is actually prime and reports how many distinct values g can produce mod p. Neither of these needs to be secret. SSH usually reads a version of these two numbers straight out of a published standard rather than generating them fresh — the security never depended on hiding them.
Step 2 — the private secrets. Alice and Bob each typed a number nobody else sees, not even displayed back to you. Real SSH generates these randomly, fresh for every single connection, using the operating system's cryptographically secure random number generator rather than anything predictable.
Step 3 — what the eavesdropper gets. Their entire view is four numbers: p, g, and the two values Alice and Bob computed and sent to each other. With a small prime, you can sometimes brute-force the secret from these four numbers by hand. With the 2048-bit or larger primes SSH actually uses, the same brute force would take longer than the universe has existed.
Step 4 — the payoff. Alice and Bob each combined the number they received with their own private secret, and landed on the same result, independently, without ever sending that result to each other. That shared number becomes the key SSH uses to encrypt your password, your keystrokes, and everything else in your session.
Takeaways
Run the demo two or three times with different numbers. Try a prime that is not actually prime and watch it get rejected. Try a weak base and see the reported cycle length drop. Each failure teaches you something a working example cannot: why the constraints on p and g exist in the first place.
The next time your terminal prints "Are you sure you want to continue connecting?" you will know exactly what conversation your laptop just had with the numbers behind the scenes.