What is the harvest now decrypt later threat to CDN traffic?

Harvest now decrypt later (HNDL) is an attack strategy where adversaries record encrypted network traffic today with the intent of decrypting it once sufficiently powerful quantum computers become available. For CDN-delivered content this means sensitive API payloads, authentication tokens, and session data encrypted with classical algorithms like RSA-2048 or ECDH P-256 could be retroactively exposed. CDN operators handling financial, healthcare, or government traffic face the highest HNDL risk because this data retains value for years or decades.

What are ML-KEM and ML-DSA and why do they matter for CDN TLS?

ML-KEM (Module Lattice Key Encapsulation Mechanism, formerly Kyber) and ML-DSA (Module Lattice Digital Signature Algorithm, formerly Dilithium) are NIST-standardized post-quantum cryptographic algorithms. ML-KEM replaces classical key exchange algorithms like ECDH in TLS handshakes, while ML-DSA replaces signature algorithms like ECDSA for certificate verification. For CDN TLS termination at edge nodes, ML-KEM-768 provides quantum-resistant key agreement with approximately 1 KB of additional handshake data, making it practical for edge deployment at scale.

How do hybrid TLS handshakes work at CDN edge nodes?

Hybrid TLS handshakes combine a classical key exchange algorithm (like X25519) with a post-quantum algorithm (like ML-KEM-768) in a single TLS 1.3 handshake. The CDN edge server advertises support for the hybrid key share (X25519MLKEM768), and if the client supports it, both algorithms contribute to the shared secret. If the quantum algorithm is later broken, the classical algorithm still provides security, and vice versa. This approach adds approximately 1,100 bytes to the ClientHello and 1,200 bytes to the ServerHello but maintains backward compatibility.

What is the performance impact of post-quantum TLS on CDN latency?

Post-quantum TLS adds measurable but manageable overhead to CDN edge connections. ML-KEM-768 key encapsulation adds roughly 0.2 to 0.5 milliseconds of computation per handshake on modern hardware with AVX2 acceleration. The larger handshake messages (approximately 2.3 KB additional data for hybrid key exchange) add 1 to 3 milliseconds on high-latency mobile connections due to increased packet count. For CDN operators handling millions of TLS handshakes per second, the CPU overhead requires capacity planning but is offset by hardware acceleration becoming standard in edge server CPUs.

When should CDN operators begin migrating to post-quantum cryptography?

CDN operators should begin migration now. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Major browsers including Chrome and Firefox already support X25519MLKEM768 hybrid key exchange by default. The migration timeline for CDN operators involves three phases: enable hybrid key exchange at edge nodes immediately (lowest risk, highest impact), migrate certificate signatures to hybrid or pure PQC algorithms over 2 to 3 years, and update origin-to-edge mTLS connections over 3 to 5 years as the certificate ecosystem matures.

Quantum-Safe Cryptography for CDN: Preparing for Post-Quantum TLS

October 1, 2026 · Michael Chen · 11 min read

Quantum computers capable of breaking RSA-2048 and elliptic curve cryptography do not exist yet, but the threat they pose to CDN-delivered traffic is already real. The harvest now, decrypt later (HNDL) attack model means adversaries can record encrypted CDN traffic today and decrypt it once quantum hardware matures. For CDN operators terminating billions of TLS connections daily at edge nodes worldwide, the migration to quantum-safe cryptography is not a future consideration—it is an active infrastructure project with concrete timelines and measurable performance implications.

This article examines the post-quantum cryptographic algorithms standardized by NIST, how they integrate with TLS 1.3 at CDN edge nodes, the performance overhead of hybrid handshakes, and a phased migration strategy for CDN operators managing large-scale edge infrastructure.

Why Does Quantum Computing Threaten CDN Encryption?

Classical CDN encryption relies on two mathematical problems: the difficulty of factoring large integers (RSA) and the difficulty of computing discrete logarithms on elliptic curves (ECDH, ECDSA). Both problems are efficiently solvable by Shor’s algorithm running on a sufficiently large quantum computer. A quantum computer with approximately 4,000 logical qubits could factor a 2048-bit RSA key in hours, compared to the billions of years required by classical computers.

For CDN infrastructure, this breaks three critical security functions. First, the TLS key exchange at edge nodes (ECDH X25519 or P-256) that establishes session keys for encrypting data in transit. Second, the certificate signatures (RSA or ECDSA) that prove the CDN edge server is legitimate. Third, the mutual TLS authentication between edge nodes and origin servers that secures the internal CDN network.

Figure 1: Post-quantum migration timeline for CDN infrastructure

NIST Post-Quantum Standards for CDN

In August 2024, NIST published three post-quantum cryptography standards that form the foundation of CDN migration planning. Understanding what each standard replaces and how it performs at edge scale is essential for capacity planning.

Performance Comparison: Edge vs Origin Processing
Metric	Edge Processing	Origin Processing	Improvement
Latency (p50)	8–15 ms	120–300 ms	15–20x faster
Cache Hit Ratio	85–95%	N/A	Reduces origin load
TLS Handshake	1–5 ms (nearby PoP)	50–150 ms	10–30x faster
Bandwidth Cost	$0.01–0.04/GB	$0.05–0.12/GB	3–5x cheaper
Availability	99.99% (multi-PoP)	99.9% (single DC)	10x fewer outages

FIPS 203: ML-KEM (Key Exchange)

ML-KEM (Module Lattice Key Encapsulation Mechanism), formerly known as CRYSTALS-Kyber, replaces ECDH for key establishment in TLS handshakes. It comes in three security levels:

ML-KEM-512: 128-bit security, 800-byte public key, 768-byte ciphertext. Fastest option but lower security margin.
ML-KEM-768: 192-bit security, 1,184-byte public key, 1,088-byte ciphertext. The recommended default for CDN edge deployment.
ML-KEM-1024: 256-bit security, 1,568-byte public key, 1,568-byte ciphertext. For high-security government or financial traffic.

The key insight for CDN operators is that ML-KEM computation is fast—encapsulation and decapsulation together take approximately 0.1 milliseconds on modern hardware. The bottleneck is not CPU but bandwidth: ML-KEM-768 adds roughly 2.3 KB to the TLS handshake compared to X25519’s 64 bytes, which increases handshake packet count and matters on high-latency mobile connections.

FIPS 204: ML-DSA (Digital Signatures)

ML-DSA (Module Lattice Digital Signature Algorithm), formerly CRYSTALS-Dilithium, replaces RSA and ECDSA for certificate signatures. The signature sizes are substantially larger than classical counterparts:

ML-DSA-44: 2,420-byte signature, 1,312-byte public key (vs ECDSA P-256: 64-byte signature, 33-byte public key)
ML-DSA-65: 3,309-byte signature, 1,952-byte public key
ML-DSA-87: 4,627-byte signature, 2,592-byte public key

Certificate chain sizes in TLS expand significantly with ML-DSA. A typical CDN certificate chain (leaf + intermediate + root) with ML-DSA-65 signatures would be approximately 15 KB versus 3 KB with ECDSA, pushing TLS handshakes beyond a single TCP congestion window and adding a round trip on new connections.

FIPS 205: SLH-DSA (Stateless Hash-Based Signatures)

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), formerly SPHINCS+, provides an alternative signature scheme based on hash functions rather than lattice mathematics. Its security assumptions are more conservative (hash functions are well-studied), but signature sizes are significantly larger (up to 49 KB). CDN operators should consider SLH-DSA for long-lived root certificates and code signing where signature size is less critical than cryptographic confidence.

Hybrid TLS Handshakes at CDN Edge

The transition strategy for CDN providers is hybrid key exchange: combining a classical algorithm with a post-quantum algorithm in a single TLS 1.3 handshake. If either algorithm is secure, the connection is secure. This eliminates the risk of deploying a post-quantum algorithm that later proves vulnerable while still providing protection against quantum attack.

Figure 2: Hybrid TLS 1.3 handshake combining X25519 and ML-KEM-768

Chrome and Firefox have shipped X25519MLKEM768 as the default key exchange since late 2024. Cloudflare reports that over 15% of TLS connections to their edge network already use the hybrid handshake. For CDN operators, enabling this at edge nodes requires updating the TLS library (OpenSSL 3.4+ or BoringSSL) and configuring the preferred key share groups.

# Nginx configuration for hybrid PQC key exchange
ssl_ecdh_curve X25519MLKEM768:X25519:P-256;

# OpenSSL 3.4+ provider configuration
[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqs_sect

[oqs_sect]
activate = 1
module = /usr/lib/ossl-modules/oqsprovider.so

Performance Impact at CDN Scale

Deploying post-quantum cryptography at CDN scale introduces three measurable performance vectors that require careful monitoring and optimization.

Handshake Size Increase

The X25519MLKEM768 hybrid handshake adds approximately 2,300 bytes to the combined ClientHello and ServerHello compared to X25519 alone. For most broadband connections, this fits within the initial TCP congestion window and adds negligible latency. However, on lossy mobile networks (3G or congested LTE), the larger handshake may span additional packets, adding one round-trip time (50 to 150 milliseconds on cellular connections).

Computational Overhead

ML-KEM-768 encapsulation and decapsulation are remarkably efficient: approximately 50 microseconds combined on a modern x86 CPU with AVX2 instructions. At CDN edge servers handling 100,000 new TLS handshakes per second, this adds roughly 5 CPU-seconds of overhead per second—less than 1% of a single modern core. The computational cost of PQC key exchange is actually lower than RSA-2048 key exchange, which CDNs supported for years.

Certificate Size Impact

When ML-DSA certificates are deployed (Phase 2 of migration), the TLS handshake size increases substantially. A three-certificate chain with ML-DSA-65 signatures occupies approximately 15 KB, compared to 3 KB for an equivalent ECDSA chain. CDN operators should plan for certificate compression (RFC 8879) and investigate TLS certificate caching strategies to amortize this overhead across connections.

# Measuring PQC handshake performance
# Using OpenSSL s_time for benchmark
openssl s_time -connect edge.example.com:443 \
  -new -time 10 \
  -groups X25519MLKEM768

# Compare with classical handshake
openssl s_time -connect edge.example.com:443 \
  -new -time 10 \
  -groups X25519

# Check negotiated key exchange
openssl s_client -connect edge.example.com:443 \
  -groups X25519MLKEM768 2>&1 | \
  grep "Server Temp Key"
# Expected: Server Temp Key: X25519MLKEM768, 1184 bits

CDN-Specific Migration Challenges

CDN operators face migration challenges beyond standard web server PQC deployment. The distributed nature of CDN infrastructure introduces unique coordination requirements that do not apply to centralized server deployments.

Edge Node Fleet Heterogeneity

Large CDN networks run diverse hardware across hundreds of PoPs. Older edge servers may lack AVX2 support, making lattice-based cryptography 10 to 50 times slower than on modern hardware. CDN operators need a hardware inventory that maps PQC capability per PoP, with traffic routing rules that direct PQC-capable connections to nodes with hardware acceleration. This mirrors the approach used when deploying HTTP/3 and QUIC where QUIC-capable clients were routed to edge nodes with UDP offload capabilities.

Origin-to-Edge mTLS Migration

CDN internal networks use mutual TLS between edge nodes, shield nodes, and origin servers. Migrating these connections to PQC requires coordinating certificate rollover across thousands of nodes simultaneously. A phased approach using hybrid certificates (containing both classical and PQC keys) allows gradual migration without a coordinated cutover.

HSM and Key Management

Hardware Security Modules (HSMs) that store CDN TLS private keys may not support PQC algorithms. CDN operators using FIPS 140-2 validated HSMs must wait for FIPS 140-3 validated PQC-capable HSMs or implement hybrid key storage where the PQC private key resides in software while the classical key remains in the HSM. This is an area where zero trust architecture principles help—compartmentalizing key material reduces the blast radius of any single compromise.

Migration Roadmap for CDN Operators

The practical migration path follows three phases, each with increasing complexity and decreasing urgency.

Phase 1: Hybrid Key Exchange (Deploy Now)

Enable X25519MLKEM768 at edge nodes. This is the highest-impact, lowest-risk change: it protects new connections against HNDL attacks, is fully backward compatible (clients that do not support PQC fall back to X25519), and adds minimal performance overhead. Most modern TLS libraries support this out of the box.

Phase 2: Certificate Migration (2027–2029)

Migrate edge TLS certificates to hybrid signatures (ECDSA + ML-DSA). This requires Certificate Authority support for PQC certificates, which is actively being developed but not yet widely available. CDN operators should begin testing with self-signed PQC certificates in staging environments and work with their CA providers on migration timelines.

Phase 3: Full Stack PQC (2029–2032)

Complete migration of all cryptographic paths: edge-to-origin mTLS, internal service mesh, key management systems, and logging infrastructure. Remove classical-only fallback paths once the PQC ecosystem has matured sufficiently to eliminate backward-compatibility requirements.

The urgency of Phase 1 cannot be overstated. Every TLS connection at a CDN edge node that uses classical-only key exchange is potentially vulnerable to HNDL attacks. The cryptographic community estimates that sensitive data encrypted today should have a protection horizon of 10 to 15 years—well within the projected timeline for cryptographically relevant quantum computers.