Post-Quantum Cryptography Latency: The TL;DR
- PQC algorithms (like Kyber and Dilithium) produce massive public keys and signatures compared to RSA/ECC.
- These large payloads exceed the standard 1500-byte MTU, forcing TLS handshakes to fragment across multiple TCP packets.
- Packet loss during a fragmented PQC handshake triggers TCP Head-of-Line blocking, amplifying connection latency.
- ZKP Validation Sandbox Explore Zero-Knowledge Proofs as an alternative to large PQC signatures.
- WebXR Frame Auditor See how network latency destroys VR frame pacing.
1 What is Post-Quantum Cryptography (PQC)?
Post-Quantum Cryptography (PQC) refers to a new generation of cryptographic algorithms designed specifically to run on classical computers (like x86 and ARM processors) while remaining mathematically secure against cryptographic attacks from future quantum supercomputers.
Current public-key encryption standards—such as RSA (Integer Factorization) and ECDSA (Elliptic Curve Discrete Logarithms)—are fundamentally vulnerable to Shor's Algorithm. When functionally coherent, large-scale quantum computers are built, Shor's algorithm will allow them to crack these asymmetric keys exponentially faster than classical brute-force, collapsing the security architecture of the modern internet (TLS, HTTPS, VPNs, and Blockchains).
2 NIST Standardization (FIPS 203, 204, 205)
To prepare for Q-Day, the U.S. National Institute of Standards and Technology (NIST) initiated a grueling multi-year competition to evaluate and standardize mathematically quantum-resistant algorithms.
Unlike RSA and ECC, the new NIST algorithms are primarily based on Lattice-based cryptography and Hash-based cryptography, which do not rely on prime factorization or elliptic curves.
Lattice-Based
Relies on the mathematical difficulty of finding the shortest or closest vector in a multi-dimensional, complex lattice grid. (Used by Kyber and Dilithium).
Hash-Based
Relies purely on the collision resistance of cryptographic hash functions (like SHA-2/SHA-3) to create highly secure, but massively bulky signatures. (Used by SPHINCS+).
3 Kyber (FIPS 203: ML-KEM)
Kyber (Module-Lattice-Based Key-Encapsulation Mechanism) is NIST’s chosen standard for general encryption and secure key exchange over the internet. It is intended to directly replace ECDH (Elliptic Curve Diffie-Hellman) in TLS handshakes.
| Level | Security Equivalence | Public Key Size | Ciphertext Size |
|---|---|---|---|
| Kyber-512 | AES-128 (Category 1) | 800 Bytes | 768 Bytes |
| Kyber-768 | AES-192 (Category 3) | 1,184 Bytes | 1,088 Bytes |
| Kyber-1024 | AES-256 (Category 5) | 1,568 Bytes | 1,568 Bytes |
Kyber is remarkably fast—often outperforming classical elliptic curves in raw CPU cycles. However, as the table shows, its public keys and ciphertexts are roughly 30 to 50 times larger than a standard 32-byte Curve25519 payload. This massive increase in byte transmission directly impacts network latency.
4 Dilithium (FIPS 204: ML-DSA)
Dilithium (Module-Lattice-Based Digital Signature Algorithm) is NIST’s primary standard for Digital Signatures (e.g., verifying a server's identity or authenticating software updates). It will replace RSA and ECDSA.
While Dilithium executes very quickly, its payloads are exceptionally large. A standard Dilithium2 (Security Level 2) public key is 1,312 bytes, and the resulting signature is 2,420 bytes. When a server sends a TLS certificate chain containing 3 or 4 Dilithium signatures, the total handshake payload can easily swell past 10 Kilobytes.
5 Falcon (FIPS 205: FN-DSA)
Falcon (Fast-Fourier Lattice-based Compact Signatures) is NIST's secondary digital signature standard, designed specifically for use cases where bandwidth and payload size are heavily constrained.
A Falcon-512 signature is only 666 bytes, making it highly attractive for protocols with strict packet limitations (like DNSSEC or IoT devices). The architectural trade-off is that Falcon's signing process is highly complex, requiring heavy floating-point mathematics, making it difficult to implement securely on low-power hardware without introducing side-channel vulnerabilities.
6 SPHINCS+ (FIPS 205: SLH-DSA)
SPHINCS+ (Stateless Hash-Based Digital Signature Algorithm) was standardized as a conservative, ultra-safe fallback. Because it relies entirely on well-understood hash functions (like SHA-256) and uses no complex lattice mathematics, its theoretical security guarantees are practically bulletproof.
7 The TCP MTU Limit & Packet Fragmentation
The core issue simulated by this sandbox is Packet Fragmentation. On the internet, the standard Maximum Transmission Unit (MTU) for a network packet is 1,500 bytes. Once you subtract standard IPv4 and TCP headers, you are left with a Maximum Segment Size (MSS) of roughly 1,460 bytes.
A traditional classical cryptography payload (e.g., an X25519 key exchange + ECDSA signature) fits comfortably inside a single 1,460-byte TCP packet. However, a full Post-Quantum TLS handshake (requiring Kyber + Dilithium) often exceeds 5,000 to 10,000 bytes.
This forces the router to slice the cryptographic handshake across 3, 5, or even 10 separate TCP packets. If even a single one of those packets is dropped due to network congestion, TCP congestion control halts the entire handshake until the missing packet is retransmitted—causing severe latency spikes.
8 TLS 1.3 Handshake Impact
The TLS 1.3 protocol was designed to be blazing fast, requiring only 1 Round Trip Time (1-RTT) to establish a secure connection. The client sends its Key Share in the very first ClientHello packet.
In a PQC world, the client must embed a massive 1,184-byte Kyber-768 public key directly into the ClientHello. Worse, the server's ServerHello must return a Kyber Ciphertext (1,088 bytes) AND an entire certificate chain signed by Dilithium (thousands of bytes).
While the CPU encryption math is fast, the sheer physics of pushing 10KB of data through a constrained connection (like a 3G mobile network or a high-latency satellite uplink) can add hundreds of milliseconds of delay to every single API request.
9 The Hybrid Cryptography Approach (X25519Kyber768)
Because these new algorithms are mathematically young (only a few years old), security engineers are terrified of a sudden algorithmic breakthrough that could break Lattice cryptography using a classical computer.
To mitigate this risk, Google Chrome and Cloudflare have pioneered Hybrid Key Exchange (X25519Kyber768). This merges a classical elliptic curve (X25519) and a post-quantum algorithm (Kyber768) into the same handshake.
The shared secrets from both algorithms are concatenated and hashed together. If a quantum computer breaks the RSA/ECC, the Kyber wrapper keeps the connection secure. If a mathematician discovers a classical flaw in Kyber lattices, the ECC wrapper keeps it secure. The trade-off is an even larger initial packet footprint.
10 QUIC & HTTP/3 Amplification Mitigation
The transition to PQC creates a severe vulnerability in UDP-based protocols like QUIC (HTTP/3). In QUIC, to prevent Denial-of-Service (DoS) amplification attacks, a server is strictly forbidden from sending more than 3 times the amount of data it receives from an unverified client (the 3x Amplification Limit).
If a client sends a small ClientHello, the server might need to respond with 10KB of Post-Quantum certificates. Because 10KB exceeds the 3x limit, the QUIC server is forced to halt the handshake and demand a Retry token from the client, instantly introducing a full extra network round-trip penalty (2-RTT). Engineering teams are actively restructuring QUIC ALPN limits and exploring Certificate Compression algorithms (like Brotli/Zstd) to solve this massive bottleneck.