In Half 2 we put two contenders within the ring: classical Diffie-Hellman / X25519 (tiny, quick, quantum-doomed) and post-quantum ML-KEM-768 (quantum-safe, chunky, new). Now it’s time for the primary occasion. Let’s put them aspect by aspect from each angle that issues, after which reveal why the neatest transfer isn’t to crown a winner in any respect.
All the things right here you’ll reproduce your self within the hands-on lab in Half 4. These aren’t numbers I’m asking you to belief; they’re numbers you’ll measure.
Spherical 1: Measurement on the wire
That is the place the distinction jumps proper out:
| X25519 | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 | |
|---|---|---|---|---|
| Public key | 32 B | 800 B | 1184 B | 1568 B |
| Response (ciphertext) | 32 B | 768 B | 1088 B | 1568 B |
| Shared secret | 32 B | 32 B | 32 B | 32 B |
| Suits in a single IKE message (≤1280 B)? | ✅ sure | ✅ sure | ❌ wants fragmentation | ❌ no |
X25519’s 32-byte keys are adorably tiny. ML-KEM’s are 25–50× bigger, large enough that ML-KEM-768 forces IKE fragmentation (splitting one logical message throughout a number of packets). Tuck that phrase away: fragmentation is the thread that runs by means of this whole pillar, and also you’ll see it with your personal eyes within the packet captures subsequent put up.
Spherical 2: Latency (spherical journeys)
| Mode | Spherical journeys | Messages |
|---|---|---|
| X25519 solely | 2 | IKE_SA_INIT → IKE_AUTH |
| Hybrid X25519 + ML-KEM | 3 | IKE_SA_INIT → IKE_INTERMEDIATE → IKE_AUTH |
Going hybrid provides one full spherical journey, measurable however small in observe (usually a couple of milliseconds on a LAN). Since a handshake occurs as soon as per tunnel (with rekeying each few hours), that is nothing to lose sleep over.
Spherical 3: Compute value (the shock)
A standard fable: “post-quantum” means “painfully gradual.” For ML-KEM, the reverse is nearer to the reality. Its lattice operations are genuinely quick, in the identical ballpark as, and sometimes sooner than, an elliptic-curve scalar multiplication.
Tough per-operation value on trendy x86 (from revealed eBACS/SUPERCOP benchmarks, not measured in our lab):
| Operation | X25519 | ML-KEM-768 |
|---|---|---|
| Key technology | ~50–65k cycles | ~30k cycles |
| Derive shared secret / encapsulate | ~50–65k cycles | ~45k cycles |
| Decapsulate | n/a | ~35k cycles |
Add it up and the totals land in the identical vary. ML-KEM-768 shouldn’t be the bottleneck, not even shut. Once we time the true handshakes in Half 4, you’ll see the hybrid model prices about 1 ms greater than classical, and primarily all of that’s the additional community spherical journey, not the crypto.
Spherical 4: Safety
| X25519 | ML-KEM-768 | |
|---|---|---|
| Classical safety | ~128-bit | ~192-bit |
| Quantum safety | ❌ damaged by Shor’s algorithm | ✅ no identified quantum assault |
| Standardised | RFC 7748 (2016) | FIPS 203 (2024) |
| Deployment maturity | Very excessive | Rising |
And there’s the rub. X25519 is battle-tested however quantum-vulnerable. ML-KEM is quantum-safe however new and fewer field-tested. Every has precisely the weak spot the opposite doesn’t.
The decision: why not each?
Right here’s the punchline I hinted in Half 2. Neither contender clearly wins in the present day, so as a substitute of choosing a champion, we make them work collectively. A hybrid key change runs each and combines their shared secrets and techniques into the ultimate session key. The outcome:
- If ML-KEM is damaged by a future quantum assault, X25519 nonetheless offers classical safety.
- If X25519 is damaged by a quantum pc, ML-KEM offers quantum resistance.
- An attacker should break each concurrently, which is believed to be infeasible.
You get quantum security with out betting all the pieces on a brand-new algorithm, all for the worth of 1 additional spherical journey and ~2 KB per handshake.
The magic that makes it work: RFC 9370
So how will we truly wire two key exchanges into one IKEv2 handshake? Enter RFC 9370 (A number of Key Exchanges in IKEv2, 2023). It defines a clear mechanism to run further key exchanges on high of the usual IKEv2 DH change, every contributing keying materials to the ultimate keys.
The scheme is elegant:
- X25519 stays the first change, carried in the usual
IKE_SA_INITmessage: small and unchanged. - ML-KEM joins as an further change, driving in a brand-new
IKE_INTERMEDIATEspherical journey. - The ultimate session secret is derived from each shared secrets and techniques mixed.
And it’s backward appropriate: friends that don’t converse further key exchanges merely fall again to the bottom DH. Everyone’s completely satisfied. That is the sensible migration path NIST and most VPN distributors advocate: bolt PQC on with out redesigning the entire protocol.
In strongSwan config, the entire story is spelled out in a single proposal string: x25519-ke1_mlkem768
x25519 is the primary DH group in IKE_SA_INIT; ke1_mlkem768 is the primary RFC 9370 further key change, driving in IKE_INTERMEDIATE. Keep in mind that string.
The handshake, step-by-step
Right here’s the entire hybrid dance, which we’re about to look at dwell:
Initiator Responder
| |
|--- IKE_SA_INIT (KE[x25519], Ni) -------------> |
| | (~1250 B, fragmented)
|See that imbalance from Half 2? The initiator sends the huge ML-KEM public key (~1184 B) and will get again the ciphertext (~1088 B): completely different sizes, reverse instructions, precisely as a result of a KEM splits the work. And that ~1250 B public-key message is exactly why fragmentation = sure is obligatory within the lab.
Sufficient idea: let’s run it
We’ve now bought the total image: why key change is the pressing pillar, who the contenders are, how they evaluate, and why hybrid is the reply. Time to cease studying tables and begin making them.
In Half 4 we deliver up an actual hybrid tunnel, seize the packets, and run classical-vs-hybrid again to again, watching the additional spherical journey and the fragmentation seem in full element. Meet me there!
