Welcome again! In Half 1 we set the scene: a safe handshake rests on two pillars (key change and authentication), and quantum computer systems threaten each. Now we zoom in on the primary and most pressing one: key change. Why pressing? Two phrases that ought to genuinely maintain you up at evening: harvest now, decrypt later.
Let’s unpack that, then introduce the 2 algorithms that can spend the subsequent few posts going head-to-head. No instructions but; for now, let’s construct the instinct.
Diffie-Hellman: the quiet hero
Diffie-Hellman (DH) is the unsung hero behind practically each safe channel on the web. The concept is genuinely elegant: two events every generate a key pair, swap public keys over an untrusted community, and thru some lovely math they independently arrive on the similar shared secret, with out that secret ever crossing the wire. Neither facet controls the end result; each contribute. IKEv2 (the protocol behind IPsec VPNs) has at all times leaned on some taste of DH as its main key change.
So what’s the issue? DH, in each taste, falls aside towards a sufficiently highly effective quantum pc working Shor’s algorithm. Such a machine might derive the shared secret from the general public keys alone, the precise factor DH was designed to make inconceivable.
Why “sometime” is already an issue right now
Right here’s the half that journeys folks up. “Quantum computer systems can’t do that but,” you may say, “so why panic?” Due to the actually nasty twist:
An attacker can file your encrypted site visitors right now and easily waitdecrypting it years later, the second quantum {hardware} grows up.
That’s “harvest now, decrypt later.” The risk is delayed. It doesn’t matter that no quantum pc can crack your handshake this afternoon; what issues is whether or not the info you’re sending this afternoon will nonetheless be delicate when one can. Medical data, monetary information, state secrets and techniques, your organization’s crown jewels: loads of it has a shelf life measured in many years.
So the query isn’t “when will quantum computer systems arrive?” It’s “is something I’m transmitting right now nonetheless going to matter once they do?” If sure, your key change must be quantum-safe now. That is why post-quantum key change is the hearth alarm, not the gradual rebuild.
Publish-quantum cryptography exists exactly to slam this door shut. On this pillar we’ll use ML-KEMNIST’s standardised PQC key encapsulation mechanism. And, crucially, we’ll use it alongside classical DH, not as an alternative of it. Why alongside? Maintain that thought; it’s the punchline of Half 3.
Within the classical nook: X25519
Each good showdown wants correct introductions, so let’s meet our fighters.
X25519 is a contemporary, high-performance taste of Diffie-Hellman constructed on Curve25519 (an elliptic curve designed by Daniel Bernstein). You’ll additionally see it referred to as ECDH (Elliptic Curve Diffie-Hellman), or referred to by its group quantity #31 in IKE. It’s the really helpful classical DH algorithm right now: sooner and safer than the outdated finite-field DH teams (modp2048 and mates) or the older NIST curves (P-256).
It’s a true key change: each events contribute. All sides whips up a throwaway key pair, they swap public keys, and every computes the identical shared secret from their very own non-public key plus the opposite social gathering’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.
Within the post-quantum nook: ML-KEM
ML-KEM (Module-Lattice-Primarily based Key Encapsulation Mechanism, FIPS 203) is the brand new child on the block: a post-quantum key encapsulation algorithm standardised by NIST in 2024. It is available in three flavors:
| Identify | Safety degree | 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 candy spot for many deployments: a snug safety margin with out the additional bandwidth of ML-KEM-1024. (ML-KEM-512 is usually prevented; its margin is taken into account a bit skinny for long-term safety.) In order that’s what our lab makes use of.
That “Module-Lattice-Primarily based” within the title is doing actual work, by the best way: ML-KEM’s safety rests on a lattice math downside that quantum computer systems don’t have any recognized shortcut for. We gained’t dive into that math right here; the essential factor for now could be the headline: no recognized quantum assault.
The twist that confuses everybody: KEM ≠ key change
Right here’s the gotcha that journeys up newcomers, so let’s hit it head-on. ML-KEM is a Key Encapsulation Mechanism, not a symmetric Diffie-Hellman-style change. The mechanics are genuinely totally different:
- In DH, each sides do the identical factor (generate a pair, swap publics, derive the key). It’s symmetric.
- In a KEMthe work is cut up. One social gathering generates a key pair and sends its public key. The opposite social gathering runs an encapsulation algorithm on that public key (which spits out each a ciphertext and a shared secret) and sends again the ciphertext. Solely the unique social gathering, holding the non-public key, can run decapsulation on that ciphertext to recuperate the similar shared secret.
So as an alternative of “each side combine their halves,” it’s “I ship you a lockbox, you place a secret in it and lock it, solely I can open it.” Identical vacation spot (a shared secret neither eavesdropper can compute), however a unique path to get there. Maintain this imbalance in thoughts: it’ll clarify why, after we seize the packets in Half 4, the public key and the ciphertext are totally different sizes flying in reverse instructions.
The place we’re headed
So now we’ve obtained our two fighters within the ring:
- X25519: tiny, quick, battle-tested… and quantum-doomed.
- ML-KEM-768: quantum-safe, surprisingly fast… however new, and chunky on the wire.
Neither one clearly wins right now, which units up the central query of the subsequent submit: if the traditional is doomed and the newcomer is unproven, which will we decide? (Trace: it’s a trick query, and the reply is the entire cause this works.)
In Half 3 we’ll put these two facet by facet in a correct head-to-head (measurement on the wire, latency, compute price, safety), after which reveal the elegant resolution that lets us cease selecting and use each. See you there!
