ZeonTools
The Quantum Threat (Shor's Algorithm)
Currently, the entire internet is secured by public-key cryptography (RSA and Elliptic Curve Cryptography like ECDSA/X25519). These algorithms rely on the extreme difficulty of factoring large numbers or solving the discrete logarithm problem.
In 1994, Peter Shor published Shor's Algorithm, a quantum algorithm capable of solving these problems exponentially faster than a classical computer. While Cryptographically Relevant Quantum Computers (CRQCs) do not exist yet, nation-states are currently executing "Store Now, Decrypt Later" (SNDL) attacks—harvesting encrypted internet traffic today with the intention of decrypting it when a quantum computer is built.
NIST PQC Standards (FIPS 203 & 204)
To combat the quantum threat, the National Institute of Standards and Technology (NIST) ran a multi-year competition to select new, quantum-resistant algorithms based on advanced mathematics (like structured lattices). In August 2024, NIST published the finalized standards:
- FIPS 203 (ML-KEM): Module-Lattice-Based Key Encapsulation Mechanism. Originally known as CRYSTALS-Kyber, this is used to securely exchange symmetric keys over an untrusted network.
- FIPS 204 (ML-DSA): Module-Lattice-Based Digital Signature Algorithm. Originally known as CRYSTALS-Dilithium, this is used for server authentication (TLS certificates).
Hybrid Cryptography (RFC Drafts)
Because PQC algorithms rely on relatively novel mathematics compared to the decades of battle-testing behind Elliptic Curves, security experts advise against dropping traditional algorithms entirely.
The IETF standardizes Hybrid Key Exchange (e.g., X25519Kyber768Draft00). This concatenates a classical X25519 key share with an ML-KEM key share. For an attacker to break the encryption, they would need to break both the elliptic curve math (using a quantum computer) AND the lattice math (which quantum computers struggle with). While this guarantees maximum security, it exacerbates the network latency problem by combining both payload sizes into a single TLS handshake.
MTU & TCP initcwnd Bottlenecks
The transition to PQC introduces a severe network performance penalty. A traditional ECDSA signature is ~64 bytes. The PQC equivalent, ML-DSA-65, requires over 5,200 bytes.
The standard internet TCP Maximum Transmission Unit (MTU) is ~1,500 bytes. Because PQC payloads greatly exceed this, the server's TLS Certificate must be fragmented across 4 to 7 TCP packets.
- Initial Congestion Window (initcwnd): Modern Linux kernels allow sending ~10 TCP packets before requiring an acknowledgment (ACK). As long as the PQC payload is smaller than `10 * MTU`, it can be sent in a single flight.
- Packet Drop Amplification: If even a single packet is dropped due to network congestion (common on Mobile/3G networks), the entire TLS handshake halts. The client must wait for a TCP timeout (RTO) and retransmission, which can add hundreds of milliseconds of latency to the connection.