Post-Quantum TLS 1.3 Cuts Handshake Latency for Edge APIs

Cloudflare just hit a milestone that should make every edge API team pay attention: 52% of their TLS 1.3 traffic now runs ML-KEM hybrid key exchange. That's not a pilot. That's production at planetary scale. The post-quantum transition isn't coming. It's here, and the latency numbers are surprisingly good.

What Changed in 2026

NIST standardized ML-KEM (formerly Kyber) in 2024. Since then, browser vendors and CDN operators have been racing to ship hybrid handshakes — classical X25519 plus ML-KEM-768 or ML-KEM-1024 — without breaking existing infrastructure. The hybrid approach means you get quantum resistance today while maintaining backward compatibility with every client that speaks TLS 1.3.

The Latency Reality Check

Everyone assumed post-quantum key exchange would murder handshake performance. Larger public keys (1184 bytes for ML-KEM-768, 1568 for ML-KEM-1024 vs 32 for X25519), bigger ciphertexts, more CPU cycles. Reality turned out more nuanced.

Parameter	X25519	ML-KEM-768 Hybrid	ML-KEM-1024 Hybrid
Public key size	32 bytes	1,216 bytes	1,600 bytes
Ciphertext size	32 bytes	1,088 bytes	1,568 bytes
Keygen (cycles)	~100k	~180k	~290k
Encaps (cycles)	~100k	~250k	~400k
Decaps (cycles)	~100k	~280k	~450k

But here's the kicker: on modern CPUs with AVX2/AVX-512, the extra compute is hidden by network RTT. Cloudflare's production data shows median handshake latency increased by 1-3ms globally. At the 99th percentile, it's 5-8ms. For edge APIs where you're already fighting 20-50ms RTTs, that's noise.

💡

TipEnable hybrid ML-KEM now on your edge termination. The compatibility risk is near zero, and you'll be ahead of the compliance curve when PCI-DSS 4.1 and FedRAMP start mandating PQC.

Migration Checklist for Edge Teams

Don't wait for your CDN vendor to flip the switch. Here's what you can do this sprint:

bash

# 1. Verify your TLS library supports hybrid KEMs
openssl ciphers -v | grep -i kyber

# 2. Test handshake latency with your actual payload sizes
curl -w "@curl-format.txt" -o /dev -s https://api.yourdomain.com/health

# 3. Check certificate chain size — PQC certs add ~1KB
openssl s_client -connect api.yourdomain.com:443 -servername api.yourdomain.com < /dev/null

# 4. Monitor ClientHello sizes in your logs
grep -E "ClientHello.*kyber" /var/log/nginx/access.log | head -20

If you're terminating TLS at the application layer (Go, Rust, Node), upgrade your crypto library first. Go 1.22+, Rust's rustls 0.23+, and Node 22+ all ship hybrid ML-KEM support. Test with real client traffic before enabling broadly.

Payload Growth Is Real — Plan For It

The 1-2KB handshake bloat matters for two scenarios: IoT devices on cellular where every byte costs money and battery, and high-frequency API chatter where you're doing fresh handshakes per request (please stop doing that). Session resumption and 0-RTT become even more critical with PQC.

"
The teams winning at PQC migration aren't the ones with the fanciest crypto. They're the ones who instrumented their handshake latency before the switch and can prove the regression is negligible.
— Cloudflare TLS Team Lead

What's Next

ML-DSA (Dilithium) signatures are the other half of the PQC puzzle. NIST standardized those too, but TLS integration lags behind KEMs. Expect hybrid certificate chains (RSA/ECDSA + ML-DSA) to hit browsers in late 2026. That's when handshake sizes jump another 2-3KB.

✦

ℹ️

NoteAction item: Add ML-KEM hybrid to your staging environment this week. Measure p50/p99 handshake latency against your baseline. If the delta is under 5ms at p99, ship it to production. The quantum clock is ticking, but your users won't notice.