Chapters 1 through 7 gave you every tool needed to encrypt data with a shared key, plus the math behind what comes next. But they all assume both parties already share that key. This chapter tackles the problem that kept cryptographers stuck for decades: how do two strangers agree on a shared secret when someone is listening to every word?
AES-GCM from Chapter 6 gives you confidentiality and integrity in one operation. But it requires a 256-bit key that both Alice and Bob share. If they have never met, how did they get it?
To send a secret, you need encryption. To use encryption, you need a shared secret. The obvious answer is to send the key over the channel, but the channel is insecure. Anyone listening gets the key and every future message.
This is not a theoretical concern. Every time your browser connects to a website, every time two servers communicate, every time you open a messaging app, this exact problem must be solved first. Without key exchange, symmetric encryption is useless beyond face-to-face meetings.
Pre-shared keys. Give every pair of users a unique key before they need to communicate. For 10 users, that is 45 keys. For 1,000 users, it is 499,500. For the internet, it is impossible. The number of keys grows as n(n-1)/2, and distributing them securely requires solving the very problem you are trying to avoid.
Trusted couriers. Send someone with the key in a locked briefcase. This works for embassies. It does not work for a billion HTTPS connections per second. Physical delivery is slow, expensive, and does not scale.
Trusted third party. A central server that knows every key and relays them to the right users. This works until the server is compromised, and then every key is exposed at once. It is a single point of failure for the entire system.
This was an open problem for decades. Cryptographers assumed that sharing a secret required a pre-existing secure channel. In 1976, Whitfield Diffie and Martin Hellman published a paper that changed everything: a way for two parties to create a shared secret over a completely public channel.
The Diffie-Hellman key exchange lets two people create a shared secret while an eavesdropper watches every message. The core idea is surprisingly simple, and a paint-mixing analogy makes it click.
Eve sees the common color and both mixtures. But separating a mixture back into its components is practically impossible. She cannot recover either secret color, and without a secret color she cannot produce the shared secret.
Now replace colors with numbers and mixing with a math operation called modular exponentiation (explained in the next section). Alice and Bob agree on a large prime and a generator . Alice picks a secret exponent , computes , and sends A publicly. Bob does the same with his secret , sending .
Alice computes . Bob computes . Both equal . The shared secret is identical, yet neither secret exponent ever crossed the channel.
Chapter 7 introduced groups, generators, and finite fields. Here is how Diffie-Hellman uses them. Three ideas make the protocol work.
Think of a clock. After 12, you wrap back to 1. Modular arithmetic works the same way: pick a number (the modulus), and after you reach it, wrap around. 17 mod 5 = 2, because 17 divided by 5 leaves a remainder of 2. All arithmetic in Diffie-Hellman happens modulo a prime number p.
Modular exponentiation means raising a number to a power, then taking the remainder. Computing . For small numbers this is trivial. For large numbers, an algorithm called repeated squaring makes it fast even when the exponent has hundreds of digits.
Take a prime p = 23 and the numbers 1 through 22. Under multiplication mod 23, this set forms a group: you can multiply any two elements and the result is always another element in the set. The set is "closed" under this operation, meaning you never escape the set no matter what you multiply.
A generator is a special element whose successive powers produce every element in the group. For p = 23, the number 5 is a generator: = 5, = 2, = 10, and so on through all 22 elements before returning to 1. Diffie-Hellman uses a generator because it guarantees the shared secret can be any element in the group.
Forward (easy): given g, a, and p, computing takes microseconds. Even with numbers hundreds of digits long, the computation finishes instantly using repeated squaring.
Backward (hard): given g, p, and the result , recovering the exponent a requires solving the discrete logarithm problem. For a 2048-bit prime, the best known algorithms need roughly operations. This one-way property is the trapdoor that makes Diffie-Hellman secure.
Numbers 1 through 22 are arranged on a clock. Each step computes the next power of the generator g. Watch how the powers visit every position before cycling back to 1.
Watch Diffie-Hellman happen step by step with numbers small enough to follow by hand. Adjust the private exponents, change the prime, and see how Alice and Bob always arrive at the same shared secret while Eve is left in the dark.
Pick a prime, adjust the secret exponents, and watch two parties independently arrive at the same shared secret.
The small primes in the demo are intentionally breakable. Real Diffie-Hellman operates at a completely different scale.
The small primes in the demo above (23, 47, 97) are intentionally tiny. An attacker could brute-force the discrete log for those in microseconds. Real Diffie-Hellman uses primes of 2048 bits or more. That is a number with over 600 decimal digits.
NIST recommends 2048-bit primes for 112-bit security (meaning an attacker would need roughly 2^112 operations to break it, far beyond any computer) and 3072-bit primes for 128-bit security. The private exponents must also be large enough to prevent attacks that exploit small exponent spaces.
This is the first time in this course that security depends on a computational hardness assumption. AES resists attacks because of the structure of the cipher itself. Diffie-Hellman is secure only because the discrete logarithm problem is believed to be hard. If someone finds a fast algorithm for discrete logs, the protocol breaks completely. This distinction matters when we discuss quantum computing in Chapter 16.
Elliptic curves provide the same trapdoor property as modular exponentiation, but over a different mathematical structure. Understanding the geometry makes ECDH click.
An elliptic curve is the set of points (x, y) satisfying an equation of the form . Over the real numbers, this produces a smooth curve with a distinctive shape. The specific values of a and b determine the curve. Cryptographic standards define specific curves: P-256 uses particular values chosen by NIST.
These points form a groupunder a special addition operation: you can "add" any two points and get another point on the curve, just like with numbers mod p. This is the same group structure from Chapter 7, but the elements are points on a curve and the operation is geometric addition instead of multiplication mod p. Chapter 7 also showed what these curves look like over a finite field, which is what real implementations compute.
To "add" two points P and Q on the curve, draw a straight line through them. That line intersects the curve at exactly one more point. Reflect that intersection over the x-axis, and the result is P + Q. When P and Q are the same point, the line becomes the tangent at P, and you get point doubling: .
Scalar multiplication is just repeated addition: (k times). Computing is fast (using a doubling-and-adding algorithm, similar to repeated squaring). But given P and , recovering k is the Elliptic Curve Discrete Logarithm Problem (ECDLP). Same trapdoor, different math.
The curve plotted over the real numbers. Explore how point addition works geometrically and how scalar multiplication produces unpredictable-looking jumps.
Draw a line through P and Q (yellow dashed). It intersects the curve at a third point R' (yellow dot). Reflect R' over the x-axis (red dashed) to get the result R (green dot).
Elliptic Curve Diffie-Hellman performs the same protocol as classic DH, but over a curve. The result: equivalent security with dramatically smaller keys and faster computation.
The protocol structure is identical to classic DH. Alice and Bob agree on a curve and a base point G. Alice picks a secret number (called a scalar) a, publishes aG. Bob picks b, publishes bG. Both compute abG as the shared secret. The ECDLP from Section 6 is what keeps a and b hidden.
The practical advantage: a 256-bit ECDH key provides roughly 128-bit security, the same as a 3072-bit classic DH key. Smaller keys mean faster computation, less bandwidth, and more efficient handshakes. This is why the industry moved to curves.
2048 to 4096-bit keys. Well-studied since 1976. Slower key generation and exchange. Still allowed in most protocols but losing ground.
256-bit keys. Faster key generation and exchange. Mandatory in TLS 1.3. Default for most modern protocols. Used by your browser right now.
TLS 1.3 mandates ECDH with P-256 or X25519 (a curve designed by Daniel Bernstein). Classic finite-field DH is still permitted but rarely used. The demo below uses P-256 through the Web Crypto API, the same curve your browser uses for HTTPS.
Generate real elliptic curve key pairs and derive a shared secret using the Web Crypto API. The same algorithm your browser uses for HTTPS.
Diffie-Hellman is mathematically sound. But it has a fundamental weakness: it tells you nothing about who you are exchanging keys with. An attacker who can intercept messages can silently hijack the entire conversation.
Mallory (the name cryptographers use for an active attacker, as opposed to Eve who only eavesdrops) sits between Alice and Bob on the network. When Alice sends her public value, Mallory intercepts it and substitutes her own. She does the same to Bob. Now Mallory has a shared secret with Alice (who thinks she is talking to Bob) and a different shared secret with Bob (who thinks he is talking to Alice).
When Alice sends an encrypted message, Mallory decrypts it with her Alice-side key, reads or modifies it, re-encrypts it with her Bob-side key, and forwards it. Bob receives a valid encrypted message and has no way to detect the interception. The math is correct on every leg. The problem is that the math does not prove identity.
Key exchange without authentication is fundamentally broken. Diffie-Hellman gives you a shared secret, but it cannot tell you who holds the other half. Fixing this requires something from Chapters 8 and 9: public-key cryptography and digital signatures, which let you verify the identity of the other party before trusting the exchanged key.
No real protocol uses raw Diffie-Hellman. It is always wrapped in a larger protocol that adds authentication, key derivation, and forward secrecy. Two protocols dominate the modern landscape.
Every HTTPS connection starts with a TLS handshake. In TLS 1.3, the client and server perform ephemeral (temporary, single-use) ECDH: they generate fresh key pairs just for this session, exchange public values, derive a shared secret, then discard the private keys. The shared secret is fed through HKDF (a key derivation function that stretches and cleans up raw shared secrets into proper encryption keys) to produce the actual encryption keys.
Forward secrecy is the key property. Because the ECDH keys are ephemeral and discarded after the handshake, even if the server's long-term private key is compromised in the future, past session keys cannot be recovered. The attacker would need the ephemeral keys, which no longer exist.
The Signal Protocol (used by Signal, WhatsApp, and Google Messages) combines multiple DH operations with different key types to achieve three things at once: authentication (proving who you are talking to), forward secrecy (past messages stay safe even if a key leaks later), and asynchronous initiation (Bob does not need to be online when Alice starts the conversation).
The core idea: Bob pre-publishes some public keys on the server. When Alice wants to start a conversation, she uses those keys to perform ECDH without Bob being present. After the initial setup, the protocol continually rotates keys for every message.
Step through the TLS 1.3 handshake to see where ECDH key exchange and authentication fit together. Real P-256 keys are generated at each step.
Key exchange is a building block, not a complete solution. These guidelines reflect how modern protocols use it.
P-256 or X25519 give you equivalent security with far smaller keys. TLS 1.3 mandates ECDH. Classic finite-field DH requires 2048+ bit parameters for the same level of protection.
Generate a fresh key pair for every session and discard it afterward. Ephemeral keys provide forward secrecy: compromising a long-term key does not expose past sessions.
Key exchange without authentication is vulnerable to man-in-the-middle attacks. Always pair ECDH with digital signatures or certificates to verify the identity of the other party.
Before using a received public key, verify that it is a valid point on the expected curve. Skipping this check can let an attacker send a crafted key that leaks your private key through the math of the exchange.
The common thread: key exchange is never used alone. In every real-world protocol, it is combined with authentication (to prevent MITM), key derivation (to produce multiple keys from one shared secret), and ephemeral keys (for forward secrecy). The protocol does the hard work so you do not have to compose these pieces manually.