NIST Post-Quantum Crypto (PQC) Key-Size & Packet Latency Simulator

Model packet fragmentation and network handshake slowdowns when migrating infrastructure to ML-KEM or ML-DSA.

TLS 1.3 Handshake Analytics
Total Payload Size 4,477 B Client + Server Flights
Required TCP Packets 4 Based on 1500 MTU
Total Handshake Time 102 ms 2.1x RTT Penalties
TLS 1.3 Message Flight
Latency (ms)
Fragmentation Warning: When a TLS record exceeds the MTU (typically 1500 bytes), it is split across multiple TCP packets. If a single packet is dropped due to network loss, TCP head-of-line blocking stalls the entire connection until the missing fragment is retransmitted, massively amplifying latency.

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.
Related Advanced Concepts:

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).

The "Store Now, Decrypt Later" Threat: Adversaries are currently intercepting and storing massive volumes of encrypted global internet traffic. Even though they cannot decrypt it today, they are hoarding it with the expectation of decrypting it retroactively once a Cryptographically Relevant Quantum Computer (CRQC) becomes available (often called "Q-Day").

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.

The Payload Penalty: SPHINCS+ produces catastrophic signature sizes. A standard SPHINCS+-128s signature is roughly 7,856 bytes. Using SPHINCS+ in a highly active TLS environment would result in massive network congestion, meaning it is largely reserved for long-term root certificate signing where bandwidth is irrelevant.

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.

FAQ Frequently Asked Questions

What is Post-Quantum Cryptography (PQC)?
Post-Quantum Cryptography refers to cryptographic algorithms (usually public-key algorithms) that are thought to be secure against a cryptanalytic attack by a quantum computer. Unlike RSA and ECC, which rely on prime factorization and discrete logarithms (vulnerable to Shor's algorithm), PQC relies on lattice-based, hash-based, or multivariate mathematical problems.
Why do PQC algorithms cause network latency?
PQC public keys and digital signatures are significantly larger than traditional ECC or RSA keys. For example, a Dilithium3 signature is over 3,000 bytes, whereas an ECDSA signature is only 64 bytes. This massive increase in payload size forces the packets to be fragmented across multiple MTU frames during the TLS handshake, inducing severe latency.
What is the standard MTU limit?
The Maximum Transmission Unit (MTU) for standard Ethernet and most of the internet is 1,500 bytes. Subtracting the IP and TCP headers leaves roughly 1,460 bytes for the TLS payload. Any PQC key or signature larger than this must be broken into multiple packets, requiring the receiver to wait for all fragments before proceeding.
What is Kyber (ML-KEM)?
Kyber (officially standardized by NIST as ML-KEM) is a lattice-based Key Encapsulation Mechanism. It is designed to replace ECDHE for secure key exchange during a TLS handshake. It offers relatively small keys and ciphertexts (around 800-1100 bytes) and extremely fast execution speeds, making it the primary choice for post-quantum web traffic.
What is Dilithium (ML-DSA)?
Dilithium (NIST standardized as ML-DSA) is a lattice-based digital signature scheme. It replaces ECDSA and RSA for authenticating servers (via certificates). While its execution speed is incredibly fast, its public keys and signatures are massive (2.5KB to 4KB), making it the primary bottleneck in PQC TLS handshake latency.
What is Falcon (FN-DSA)?
Falcon (NIST standardized as FN-DSA) is another lattice-based signature scheme. Unlike Dilithium, Falcon utilizes fast Fourier transforms over NTRU lattices to achieve much smaller signatures (around 660 bytes). However, it is mathematically complex and requires floating-point arithmetic, making it difficult to implement securely on constrained embedded devices.
How does PQC impact TLS 1.3?
In TLS 1.3, the server sends its certificate (containing the public key) and the ServerKeyExchange in a single flight. With traditional crypto, this easily fits in 1 or 2 packets. With a Dilithium certificate chain, this flight can explode to 10+ packets (over 10KB of data). If packet loss occurs, TCP congestion control and retransmission will severely delay the connection establishment.
What is a Hybrid KEM?
During the transition to PQC, browsers and servers are using Hybrid Key Encapsulation Mechanisms (like X25519Kyber768). This combines a traditional elliptic curve (X25519) with a post-quantum algorithm (Kyber). If an attacker breaks Kyber, the connection is still protected by X25519, providing a fail-safe during the experimental rollout phase.
Can QUIC mitigate PQC fragmentation latency?
Yes. QUIC (HTTP/3) operates over UDP and manages its own cryptography and packet assembly. While it still suffers from MTU limits, QUIC avoids the TCP head-of-line blocking problem. If one PQC certificate fragment is dropped, QUIC can continue processing other independent streams while waiting for the retransmission, slightly mitigating the UX impact.
When will Quantum Computers break RSA/ECC?
Experts estimate a cryptographically relevant quantum computer (CRQC) capable of running Shor's algorithm to break 2048-bit RSA could exist within 10 to 15 years. However, because of "Store Now, Decrypt Later" attacks (where adversaries harvest encrypted traffic today to decrypt tomorrow), the transition to PQC must happen immediately for sensitive data.
What does the NIST Post-Quantum Crypto (PQC) Key-Size & Packet Latency Simulator measure?
This tool simulates the network impact of transitioning to post-quantum cryptographic algorithms, specifically measuring how increased key sizes and signature sizes affect packet fragmentation and transmission latency.
Why is PQC simulation important for network infrastructure?
Post-quantum algorithms generally require significantly larger keys than traditional methods like RSA or ECC. Simulating these changes helps network architects prepare for potential bottlenecks and adjust MTU settings accordingly.
Does the simulator use the finalized NIST PQC standards?
Yes, the simulator is continually updated to reflect the latest NIST standardized algorithms, including ML-KEM (Kyber) and ML-DSA (Dilithium), ensuring accurate and relevant performance metrics.

Rate NIST Post-Quantum Crypto (PQC) Key-Size & Packet Latency Simulator

Help us improve by rating this tool.

4.9/5
154 reviews