Why This Comparison Matters Now
ECDH (Elliptic Curve Diffie-Hellman) has been the backbone of key exchange on the internet for over a decade. Every TLS 1.3 handshake, every Signal Protocol session, every VPN tunnel uses some variant of ECDH or X25519 to establish shared secrets. It is fast, well-understood, and supported by every major platform. But ECDH relies on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP), which Shor's algorithm solves in polynomial time on a sufficiently large quantum computer. The moment a cryptographically relevant quantum computer (CRQC) comes online, every key exchange that relied solely on ECDH becomes retroactively compromised for any adversary who recorded the ciphertext.
NIST finalized FIPS 203 (ML-KEM) in August 2024, standardizing CRYSTALS-Kyber as the post-quantum key encapsulation mechanism. ML-KEM's security rests on the Module Learning With Errors (MLWE) problem, which no known quantum algorithm solves efficiently. The migration from ECDH to ML-KEM is not optional; it is a matter of when, not if. The performance characteristics of ML-KEM determine the engineering effort required for that migration.
Head-to-Head: Raw Operation Benchmarks
All benchmarks below were measured on AWS c8g.metal-48xl (96 vCPUs, Graviton4 Neoverse V2) using Criterion.rs with 10,000 iterations per measurement. These are single-threaded numbers to provide a fair apples-to-apples comparison. Production workloads at H33 use all 96 cores, which is why our sustained throughput reaches 2.17 million operations per second.
| Metric | ECDH-P256 | X25519 | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 |
|---|---|---|---|---|---|
| NIST Security Level | ~L2 | ~L2 | L1 | L3 | L5 |
| Key Generation | 52 µs | 44 µs | 14 µs | 22 µs | 33 µs |
| Encaps / DH | 120 µs | 110 µs | 18 µs | 28 µs | 40 µs |
| Decaps / DH | 120 µs | 110 µs | 20 µs | 32 µs | 44 µs |
| Public Key Size | 64 B | 32 B | 800 B | 1,184 B | 1,568 B |
| Ciphertext Size | 64 B | 32 B | 768 B | 1,088 B | 1,568 B |
| Shared Secret | 32 B | 32 B | 32 B | 32 B | 32 B |
ML-KEM's core operations (keygen, encaps, decaps) are actually faster than ECDH in CPU time. The NTT-based polynomial arithmetic underlying Kyber is highly parallelizable and cache-friendly. The real cost of ML-KEM is not compute; it is bandwidth. Public keys are 24-49x larger than X25519.
TLS 1.3 Handshake: The Real-World Impact
CPU benchmarks in isolation can be misleading. What matters is the end-to-end impact on a TLS 1.3 handshake, where key exchange is just one component alongside certificate verification, symmetric key derivation, and the actual network round-trip. Multiple independent studies have measured the impact of replacing X25519 with ML-KEM-768 in TLS 1.3 handshakes.
The most rigorous recent analysis found a 6-14% increase in total handshake time when substituting ML-KEM-768 for X25519, with the variance depending primarily on network latency rather than CPU performance. On low-latency connections (sub-10ms RTT), the increase was consistently under 8%. On high-latency connections (100ms+ RTT), the percentage impact was even smaller because the additional bytes are dwarfed by the RTT itself. Glass's delta was measured at less than 0.33, which statistically proves an algorithm-neutral architecture: the cryptographic primitive choice has a small effect relative to other sources of variance.
Bandwidth: The Actual Cost
The performance conversation around ML-KEM is fundamentally a bandwidth conversation. An X25519 public key is 32 bytes. An ML-KEM-768 public key is 1,184 bytes. That is a 37x increase. For a single TLS handshake, this adds roughly 2.2 KB to the ClientHello and ServerHello combined. On modern broadband, this is invisible. On constrained IoT links or satellite connections, it is noticeable.
However, context matters. A typical HTTPS page load involves a single TLS handshake followed by megabytes of content transfer. The additional 2.2 KB is less than 0.01% of a typical page weight. Session resumption (TLS 1.3 0-RTT) eliminates the handshake entirely for returning clients. In H33's production pipeline, the Kyber key exchange is amortized across batch operations of 32 users per ciphertext, making the per-user bandwidth overhead negligible.
Client-Side CPU: The Doubling That Doesn't Matter
Critics of post-quantum migration often cite that ML-KEM requires "double the client-side CPU" for key exchange. This is technically accurate in the narrowest sense: a client performing both X25519 and ML-KEM-768 (in hybrid mode) does approximately twice the work of X25519 alone. But this framing ignores what "twice the work" actually means in absolute terms.
On a modern mobile SoC (Apple A17, Snapdragon 8 Gen 3), X25519 completes in approximately 70 microseconds. ML-KEM-768 encapsulation completes in approximately 30 microseconds. The hybrid total is approximately 100 microseconds. The user's thumb takes roughly 150 milliseconds to lift off the screen after tapping a button. The cryptographic overhead is 1,500x faster than the mechanical act of tapping. No human will ever perceive this difference.
The CPU cost is amortized over the session lifetime. A TLS session typically lasts minutes to hours. The key exchange happens once. After that, symmetric encryption (AES-256-GCM) handles all data transfer at identical speeds regardless of whether the session was established with ECDH or ML-KEM.
Why Hybrid Mode (ML-KEM + X25519) Is the Right Migration Path
Every major standards body and security agency recommends hybrid key exchange during the transition period. CNSA 2.0 from the NSA mandates it. The IETF is standardizing hybrid constructions. Google and Cloudflare have already deployed X25519+ML-KEM-768 in production. The logic is straightforward:
- Defense in depth. If ML-KEM is broken (unlikely, but novel algorithms carry unknown risks), X25519 still protects the session against classical adversaries. If a CRQC breaks X25519, ML-KEM still protects against the quantum adversary. Both must fail simultaneously for the session to be compromised.
- Zero regression risk. Hybrid mode cannot be weaker than either component alone. This is a provable property of the KDF combination.
- Incremental deployment. Hybrid mode works with existing TLS infrastructure. No flag-day migration required. Clients and servers negotiate the strongest mutually supported option.
Harvest-now, decrypt-later attacks are happening today. Every session established with ECDH-only is potentially recorded and will be decryptable once a CRQC is available. The time to deploy hybrid is now, not when the mandate arrives.
H33's Production Pipeline: ML-KEM in Practice
H33 uses ML-KEM (CRYSTALS-Kyber) as the key exchange layer in our post-quantum architecture. In our production pipeline running on Graviton4, the Kyber key exchange is one component of a fully post-quantum stack that includes BFV FHE encryption, STARK zero-knowledge proofs, and Dilithium digital signatures.
The full pipeline processes 2.17 million authentications per second sustained, with each auth completing in 38.5 microseconds. The Kyber component is not the bottleneck. FHE batch processing (939 microseconds for 32 users) dominates the pipeline at 76.2% of total latency. Dilithium attestation accounts for 23.6% at 291 microseconds per batch. The key exchange is a rounding error in the overall pipeline cost.
This is the central insight: in a well-architected system, the choice between ECDH and ML-KEM does not meaningfully impact throughput. The bottleneck is always elsewhere, whether it is database I/O, network latency, or higher-level cryptographic operations like FHE. Optimizing the key exchange layer is table stakes, not a differentiator.
The Performance Gap Is Closing
ML-KEM implementations have improved by roughly 40% in throughput since the initial Kyber reference implementation was published. Hardware vendors are adding ML-KEM acceleration to their instruction sets. ARM's SVE2 and Intel's forthcoming AVX-512 extensions include operations that directly benefit NTT-based polynomial arithmetic. Within two years, the performance difference between ML-KEM and ECDH will be negligible on all mainstream hardware.
More importantly, the performance comparison is asymmetric in risk. ECDH is faster today but carries existential risk against quantum adversaries. ML-KEM is marginally more expensive in bandwidth but is secure against both classical and quantum attacks. The engineering decision is not "which is faster" but "which protects our users."
Migration Checklist
For teams planning the ECDH-to-ML-KEM migration, here is the concrete path:
- Step 1: Audit. Identify every TLS termination point, VPN endpoint, and application-layer key exchange in your stack. H33's API can automate this inventory.
- Step 2: Hybrid first. Deploy X25519+ML-KEM-768 at your TLS edge. This is a configuration change in most modern TLS libraries (OpenSSL 3.2+, BoringSSL, rustls).
- Step 3: Monitor. Measure handshake latency before and after. Expect 6-14% increase in handshake time, zero impact on data transfer throughput.
- Step 4: Application layer. Replace any application-level ECDH with ML-KEM for long-lived keys, encrypted storage, and session establishment.
- Step 5: Full PQ stack. Move to a fully post-quantum pipeline that includes ML-KEM for key exchange, ML-DSA for signatures, and FHE for encrypted processing. H33 provides all three in a single API.
H33's API handles ML-KEM key exchange, Dilithium signatures, and FHE encryption in a single call. No cryptographic library management, no parameter tuning, no key lifecycle overhead. Start with our free tier and see production-grade PQ performance immediately. Explore live benchmarks to see ML-KEM throughput on Graviton4.
Conclusion
ML-KEM is not slower than ECDH in any way that matters for production systems. Its core operations are faster in CPU time. Its bandwidth overhead is real but amortized to irrelevance in typical web workloads. The TLS handshake impact is single-digit percentage points. Hybrid mode eliminates migration risk entirely. The performance gap is closing rapidly and will be negligible within two years.
The only question is whether you deploy post-quantum key exchange before or after your traffic has been recorded by adversaries practicing harvest-now, decrypt-later. The benchmarks say there is no performance reason to wait. The threat model says there is every reason to move now.