ML-KEM-768 vs X25519: Handshake Performance Overhead Explained

ML-KEM-768 vs X25519: Handshake Performance Overhead Compared

The question of ML-KEM-768 versus X25519 handshake performance overhead lands differently depending on whether you are a web developer, a protocol engineer, or a blockchain node operator. The key exchange algorithms serve the same function: establishing a shared secret between two parties. But the numbers are not comparable.

X25519 uses Diffie-Hellman over Curve25519. A public key is 32 bytes. The full key exchange produces 56 bytes on the wire. ML-KEM-768, the NIST FIPS 203 standard derived from CRYSTALS-Kyber-768, works differently: the client sends a 1,184-byte public key encapsulation key, and the server responds with a 1,088-byte ciphertext. That is 2,272 bytes of key exchange material versus 64 bytes for X25519, a 35-fold increase in bytes on the wire.

Where the Overhead Actually Comes From

ML-KEM is a key encapsulation mechanism, not a Diffie-Hellman protocol. The client generates a key pair, sends the public encapsulation key to the server, the server encapsulates a random shared secret inside a ciphertext and sends it back, and the client decapsulates to recover the shared secret. Neither party performs a scalar multiplication over an elliptic curve. Instead, ML-KEM operates on polynomial rings, using the Module Learning With Errors (Module-LWE) problem as its hardness assumption.

Benchmarks on x86-64 with AVX2 optimisation. Kyber reference: CRYSTALS-Kyber team benchmarks, eBACS SUPERCOP results.

CPU Cost: Closer Than the Byte Counts Suggest

The byte sizes look alarming. The CPU cost is not. ML-KEM's polynomial operations map efficiently to modern SIMD instruction sets. With AVX2 optimisation, ML-KEM-768 key generation takes around 65 microseconds and encapsulation takes around 70 microseconds on a modern Intel or AMD processor. X25519 comes in at roughly 40 microseconds for the full scalar multiplication.

That is a 1.6 to 1.75x compute overhead, not 35x. The CRYSTALS team designed Kyber specifically to exploit the Number Theoretic Transform (NTT), a polynomial multiplication algorithm that parallelises well on modern hardware. This is fundamentally different from the RSA or ECC operations ML-KEM replaces: RSA-2048 key exchange at comparable security takes roughly 30 to 100 times longer than X25519 depending on implementation. ML-KEM-768 is actually faster than RSA for key exchange at equivalent post-quantum security levels.

Network Overhead: The Real Bottleneck

The 2,272-byte wire overhead is the practical constraint. On a 100 Mbps connection, transmitting those extra bytes takes approximately 0.18 milliseconds. On a 1 Gbps connection, 0.018 milliseconds. For most applications, this is negligible. On high-latency connections (mobile networks, satellite, cross-continental links), the extra bytes may push the handshake into an additional TCP round-trip if the client or server has a small initial congestion window.

Cloudflare measured the impact of their PQ hybrid deployment in 2023 and found the handshake size increase was approximately 5 percent across their network, with no statistically significant latency regression in median performance. Tail latency (P99) showed a measurable increase on constrained connections, specifically mobile clients with high packet loss rates.

The practical conclusion: for server-to-server communication on well-provisioned networks, the overhead is invisible. For high-volume mobile-facing APIs with aggressive performance SLAs, the additional round-trip risk is worth measuring in your specific environment.

The Hybrid X25519MLKEM768 Standard Already in Production

The industry settled on a hybrid approach rather than a direct cutover. X25519MLKEM768 combines X25519 and ML-KEM-768 in a single key exchange: both algorithms run in parallel, and the shared secrets are combined cryptographically. The result is a connection that is secure against both classical and quantum adversaries. If either algorithm is later found to be weak, the other provides a security backstop.

Google enabled X25519MLKEM768 by default in Chrome 124, shipped in April 2024. Cloudflare deployed it across their edge network. The IETF codified the hybrid construction in RFC 9370 (Multiple Key Exchanges in IKEv2) and has active drafts for TLS 1.3. As of 2026, X25519MLKEM768 is the practical standard for quantum-safe TLS key exchange.

Implications for Blockchain Node Communication

Blockchain node protocols differ from standard web TLS in one important way: connections between peers are long-lived. A Bitcoin node connection to a peer might persist for hours or days. A blockchain node making one TLS handshake per connection amortises the 2,272-byte overhead across thousands to millions of messages. The per-message cost of migrating to ML-KEM is essentially zero for node-to-node traffic.

The concern is different for blockchain applications: the signature algorithm, not the key exchange algorithm, determines on-chain security. A TLS upgrade to X25519MLKEM768 protects data in transit. It does not protect the on-chain private keys that sign transactions. Those require ML-DSA (CRYSTALS-Dilithium) or another post-quantum signature scheme at the protocol layer.

For RPC endpoints, node APIs, and wallet-to-node communication, upgrading to X25519MLKEM768 provides harvest-now-decrypt-later protection on the transport layer. This is meaningful for sensitive queries (balance lookups, transaction broadcasting) that an adversary might be recording today to decrypt after Q-Day.

Choosing Between ML-KEM-512, ML-KEM-768, and ML-KEM-1024

NIST FIPS 203 defines three ML-KEM parameter sets. ML-KEM-512 targets NIST security level 1 (roughly equivalent to AES-128). ML-KEM-768 targets level 3 (AES-192). ML-KEM-1024 targets level 5 (AES-256). For most applications, ML-KEM-768 is the recommended choice: it provides security well beyond what any known attack can approach, while keeping wire overhead manageable.

ML-KEM-1024 is appropriate for government and defence applications with long data classification periods, where the additional security margin justifies the extra 432 bytes of ciphertext. ML-KEM-512 is appropriate for heavily constrained IoT devices where bandwidth is the binding constraint. For standard web and blockchain applications, ML-KEM-768 is the right default.

Frequently Asked Questions

Is ML-KEM-768 faster or slower than X25519?

ML-KEM-768 is approximately 1.6 to 1.75 times slower than X25519 in CPU cycles on AVX2-optimised hardware. In absolute terms, the difference is around 30 to 35 microseconds per handshake. For most applications, this is imperceptible. The meaningful overhead is the additional 2,272 bytes of key exchange material on the wire, which can cause an extra TCP round-trip on constrained connections.

What is X25519MLKEM768 and should I use it?

X25519MLKEM768 is a hybrid key exchange that runs X25519 and ML-KEM-768 in parallel. It is deployed by default in Chrome 124 and Cloudflare's network. You should use it if your TLS library supports it. It provides quantum-safe security without abandoning the classical security of X25519 during the transition period.

Does upgrading to ML-KEM protect my blockchain private keys?

No. ML-KEM protects data in transit over TLS. Blockchain private keys are protected by the signature algorithm used to sign transactions. Protecting on-chain keys requires ML-DSA or another post-quantum signature scheme at the protocol layer. Transport-layer PQ and protocol-layer PQ are separate problems requiring separate solutions.

Which ML-KEM parameter set should I use for a blockchain API?

ML-KEM-768 is the recommended default. It targets NIST security level 3, provides a large security margin against known and theoretical quantum attacks, and keeps wire overhead to 2,272 bytes per handshake. ML-KEM-1024 is only necessary for applications with strict government security requirements or very long data classification periods.

When did major TLS implementations add ML-KEM support?

OpenSSL 3.5 (April 2025) added ML-KEM support. BoringSSL (used by Chromium and Android) added it in 2024. liboqs provides ML-KEM for languages without native library support. The major cloud providers (AWS, GCP, Cloudflare) have supported PQ key exchange in their TLS termination infrastructure since 2023 to 2024.