{"slug": "ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3", "title": "ML-KEM vs Diffie-Hellman: The Showdown – IPsec Series, Part 3", "summary": "ML-KEM-768 keys are 25–50× larger than X25519, forcing IKE fragmentation for ML-KEM-768, but its compute cost is comparable to or lower than X25519, adding only about 1 ms to handshake time. The recommended approach is a hybrid key exchange combining both algorithms, as defined in RFC 9370, to provide quantum safety without betting on a single new algorithm.", "body_md": "In Part 2 we put two contenders in the ring: classical **Diffie-Hellman / X25519** (tiny, fast, quantum-doomed) and post-quantum **ML-KEM-768** (quantum-safe, chunky, new). Now it’s time for the main event. Let’s put them side by side from every angle that matters, and then reveal why the smartest move isn’t to crown a winner at all.\n\nEverything here you’ll *reproduce yourself* in the hands-on lab in Part 4. These aren’t numbers I’m asking you to trust; they’re numbers you’ll measure.\n\n## Round 1: Size on the wire\n\nThis is where the difference jumps right out:\n\n| X25519 | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 | |\n|---|---|---|---|---|\n| Public key | 32 B | 800 B | 1184 B | 1568 B |\n| Response (ciphertext) | 32 B | 768 B | 1088 B | 1568 B |\n| Shared secret | 32 B | 32 B | 32 B | 32 B |\n| Fits in one IKE message (≤1280 B)? | ✅ yes | ✅ yes | ❌ needs fragmentation | ❌ no |\n\nX25519’s 32-byte keys are adorably tiny. ML-KEM’s are **25–50× larger**, big enough that ML-KEM-768 forces IKE *fragmentation* (splitting one logical message across multiple packets). Tuck that word away: **fragmentation** is the thread that runs through this entire pillar, and you’ll see it with your own eyes in the packet captures next post.\n\n## Round 2: Latency (round trips)\n\n| Mode | Round trips | Messages |\n|---|---|---|\n| X25519 only | 2 | `IKE_SA_INIT` → `IKE_AUTH` |\n| Hybrid X25519 + ML-KEM | 3 | `IKE_SA_INIT` → `IKE_INTERMEDIATE` → `IKE_AUTH` |\n\nGoing hybrid adds **one full round trip**, measurable but small in practice (typically a few milliseconds on a LAN). Since a handshake happens once per tunnel (with rekeying every few hours), this is nothing to lose sleep over.\n\n## Round 3: Compute cost (the surprise)\n\nA common myth: “post-quantum” means “painfully slow.” For ML-KEM, the *opposite* is closer to the truth. Its lattice operations are genuinely fast, in the same ballpark as, and often faster than, an elliptic-curve scalar multiplication.\n\nRough per-operation cost on modern x86 (from published eBACS/SUPERCOP benchmarks, not measured in our lab):\n\n| Operation | X25519 | ML-KEM-768 |\n|---|---|---|\n| Key generation | ~50–65k cycles | ~30k cycles |\n| Derive shared secret / encapsulate | ~50–65k cycles | ~45k cycles |\n| Decapsulate | n/a | ~35k cycles |\n\nAdd it up and the totals land in the same range. **ML-KEM-768 is not the bottleneck**, not even close. When we time the real handshakes in Part 4, you’ll see the hybrid version costs about *1 ms* more than classical, and essentially all of that is the extra network round trip, not the crypto.\n\n## Round 4: Security\n\n| X25519 | ML-KEM-768 | |\n|---|---|---|\n| Classical security | ~128-bit | ~192-bit |\n| Quantum security | ❌ broken by Shor’s algorithm | ✅ no known quantum attack |\n| Standardised | RFC 7748 (2016) | FIPS 203 (2024) |\n| Deployment maturity | Very high | Emerging |\n\nAnd there’s the rub. X25519 is **battle-tested but quantum-vulnerable**. ML-KEM is **quantum-safe but new and less field-tested**. Each has exactly the weakness the other doesn’t.\n\n## The verdict: why not both?\n\nHere’s the punchline I hinted in Part 2. Neither contender clearly wins today, so instead of picking a champion, **we make them work together.** A *hybrid* key exchange runs *both* and combines their shared secrets into the final session key. The result:\n\n- If ML-KEM is broken by a future quantum attack, X25519 still provides classical security.\n- If X25519 is broken by a quantum computer, ML-KEM provides quantum resistance.\n- An attacker must break\n**both simultaneously**, which is believed to be infeasible.\n\nYou get quantum safety without betting everything on a brand-new algorithm, all for the price of one extra round trip and ~2 KB per handshake.\n\n## The magic that makes it work: RFC 9370\n\nSo how do we actually wire two key exchanges into one IKEv2 handshake? Enter ** RFC 9370** (Multiple Key Exchanges in IKEv2, 2023). It defines a clean mechanism to run\n\n*additional*key exchanges on top of the standard IKEv2 DH exchange, each contributing keying material to the final keys.\n\nThe scheme is elegant:\n\n**X25519 stays the primary** exchange, carried in the standard`IKE_SA_INIT`\n\nmessage: small and unchanged.**ML-KEM joins as an**, riding in a brand-new*additional*exchange`IKE_INTERMEDIATE`\n\nround trip.- The final session key is derived from\n**both** shared secrets combined.\n\nAnd it’s backward compatible: peers that don’t speak additional key exchanges simply fall back to the base DH. Everybody’s happy. This is the practical migration path NIST and most VPN vendors recommend: bolt PQC on *without* redesigning the whole protocol.\n\nIn strongSwan config, the whole story is spelled out in one proposal string: `x25519-ke1_mlkem768`\n\n`x25519`\n\nis the main DH group in `IKE_SA_INIT`\n\n; `ke1_mlkem768`\n\nis the first RFC 9370 additional key exchange, riding in `IKE_INTERMEDIATE`\n\n. Remember that string.\n\n## The handshake, step by step\n\nHere’s the whole hybrid dance, which we’re about to watch live:\n\n```\nInitiator                                        Responder\n    |                                                |\n    |--- IKE_SA_INIT (KE[x25519], Ni) -------------> |\n    |<-- IKE_SA_INIT (KE[x25519], Nr) -------------- |\n    |                                                |\n    |    X25519 shared secret derived                |\n    |                                                |\n    |--- IKE_INTERMEDIATE (mlkem768 pub key) ------> |   (~1250 B, fragmented)\n    |<-- IKE_INTERMEDIATE (mlkem768 ciphertext) ---- |   (~1155 B)\n    |                                                |\n    |    ML-KEM shared secret combined with          |\n    |    X25519 secret → final IKE SA keys           |\n    |                                                |\n    |    IKE SA ESTABLISHED                          |\n```\n\nSee that imbalance from Part 2? The initiator sends the *big* ML-KEM **public key** (~1184 B) and gets back the **ciphertext** (~1088 B): different sizes, opposite directions, exactly because a KEM splits the work. And that ~1250 B public-key message is precisely why `fragmentation = yes`\n\nis mandatory in the lab.\n\n## Enough theory: let’s run it\n\nWe’ve now got the full picture: *why* key exchange is the urgent pillar, *who* the contenders are, *how* they compare, and *why* hybrid is the answer. Time to stop reading tables and start making them.\n\nIn **Part 4** we bring up a real hybrid tunnel, capture the packets, and run classical-vs-hybrid back to back, watching the extra round trip and the fragmentation appear in full detail. Meet me there!", "url": "https://wpnews.pro/news/ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3", "canonical_source": "https://blogs.cisco.com/developer/ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3", "published_at": "2026-07-20 14:00:09+00:00", "updated_at": "2026-07-22 00:11:56.832663+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-policy", "ai-research", "ai-infrastructure"], "entities": ["ML-KEM-768", "X25519", "RFC 9370", "IKEv2", "FIPS 203", "RFC 7748", "eBACS/SUPERCOP"], "alternates": {"html": "https://wpnews.pro/news/ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3", "markdown": "https://wpnews.pro/news/ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3.md", "text": "https://wpnews.pro/news/ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3.txt", "jsonld": "https://wpnews.pro/news/ml-kem-vs-diffie-hellman-the-showdown-ipsec-series-part-3.jsonld"}}