Welcome back! In Part 1 we set the scene: a secure handshake rests on two pillars (key exchange and authentication), and quantum computers threaten both. Now we zoom in on the first and most urgent one: key exchange. Why urgent? Two words that should genuinely keep you up at night: harvest now, decrypt later.
Let’s unpack that, then introduce the two algorithms that will spend the next few posts going head-to-head. No commands yet; for now, let’s build the intuition.
Diffie-Hellman: the quiet hero
Diffie-Hellman (DH) is the unsung hero behind nearly every secure channel on the internet. The idea is genuinely elegant: two parties each generate a key pair, swap public keys over an untrusted network, and through some beautiful math they independently arrive at the same shared secret, without that secret ever crossing the wire. Neither side controls the outcome; both contribute. IKEv2 (the protocol behind IPsec VPNs) has always leaned on some flavor of DH as its primary key exchange.
So what’s the problem? DH, in every flavor, falls apart against a sufficiently powerful quantum computer running Shor’s algorithm. Such a machine could derive the shared secret from the public keys alone, the exact thing DH was designed to make impossible.
Why “someday” is already a problem today
Here’s the part that trips people up. “Quantum computers can’t do this yet,” you might say, “so why panic?” Because of the truly nasty twist:
An attacker can record your encrypted traffic today and simply wait, decrypting it years later, the moment quantum hardware grows up.
That’s “harvest now, decrypt later.” The threat is delayed. It doesn’t matter that no quantum computer can crack your handshake this afternoon; what matters is whether the data you’re sending this afternoon will still be sensitive when one can. Medical records, financial data, state secrets, your company’s crown jewels: plenty of it has a shelf life measured in decades.
So the question isn’t “when will quantum computers arrive?” It’s “is anything I’m transmitting today still going to matter when they do?” If yes, your key exchange needs to be quantum-safe now. This is why post-quantum key exchange is the fire alarm, not the slow rebuild.
Post-quantum cryptography exists precisely to slam this door shut. In this pillar we’ll use ML-KEM, NIST’s standardised PQC key encapsulation mechanism. And, crucially, we’ll use it alongside classical DH, not instead of it. Why alongside? Hold that thought; it’s the punchline of Part 3.
In the classical corner: X25519
Every good showdown needs proper introductions, so let’s meet our fighters.
X25519 is a modern, high-performance flavor of Diffie-Hellman built on Curve25519 (an elliptic curve designed by Daniel Bernstein). You’ll also see it called ECDH (Elliptic Curve Diffie-Hellman), or referred to by its group number #31 in IKE. It’s the recommended classical DH algorithm today: faster and safer than the old finite-field DH groups (modp2048 and friends) or the older NIST curves (P-256).
It’s a true key exchange: both parties contribute. Each side whips up a throwaway key pair, they swap public keys, and each computes the same shared secret from their own private key plus the other party’s public key. It’s been battle-tested since 2016 (RFC 7748).
The catch? It’s quantum-vulnerable. Shor’s algorithm eats elliptic curves for breakfast. Sigh.
In the post-quantum corner: ML-KEM
ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, FIPS 203) is the new kid on the block: a post-quantum key encapsulation algorithm standardised by NIST in 2024. It comes in three flavors:
| Name | Security level | Public key | Ciphertext |
|---|---|---|---|
| ML-KEM-512 | ~128-bit classical | 800 B | 768 B |
| ML-KEM-768 | ~192-bit classical | 1184 B | 1088 B |
| ML-KEM-1024 | ~256-bit classical | 1568 B | 1568 B |
ML-KEM-768 is the sweet spot for most deployments: a comfortable security margin without the extra bandwidth of ML-KEM-1024. (ML-KEM-512 is generally avoided; its margin is considered a bit thin for long-term protection.) So that’s what our lab uses.
That “Module-Lattice-Based” in the name is doing real work, by the way: ML-KEM’s security rests on a lattice math problem that quantum computers have no known shortcut for. We won’t dive into that math here; the important thing for now is the headline: no known quantum attack.
The twist that confuses everyone: KEM ≠ key exchange
Here’s the gotcha that trips up newcomers, so let’s hit it head-on. ML-KEM is a Key Encapsulation Mechanism, not a symmetric Diffie-Hellman-style exchange. The mechanics are genuinely different:
- In DH, both sides do the same thing (generate a pair, swap publics, derive the secret). It’s symmetric.
- In a KEM, the work is split. One party generates a key pair and sends its public key. The other party runs an encapsulation algorithm on that public key (which spits out both a ciphertext and a shared secret) and sends back the ciphertext. Only the original party, holding the private key, can run decapsulation on that ciphertext to recover the same shared secret.
So instead of “both sides mix their halves,” it’s “I send you a lockbox, you put a secret in it and lock it, only I can open it.” Same destination (a shared secret neither eavesdropper can compute), but a different route to get there. Keep this imbalance in mind: it’ll explain why, when we capture the packets in Part 4, the public key and the ciphertext are different sizes flying in opposite directions.
Where we’re headed
So now we’ve got our two fighters in the ring:
- X25519: tiny, fast, battle-tested… and quantum-doomed.
- ML-KEM-768: quantum-safe, surprisingly quick… but new, and chunky on the wire.
Neither one clearly wins today, which sets up the central question of the next post: if the classic is doomed and the newcomer is unproven, which do we pick? (Hint: it’s a trick question, and the answer is the whole reason this works.)
In Part 3 we’ll put these two side by side in a proper head-to-head (size on the wire, latency, compute cost, security), and then reveal the elegant solution that lets us stop choosing and use both. See you there!