Post-quantum cryptography migration in practice

The threat of Shor's algorithm breaking RSA and Elliptic Curve Cryptography (ECC) on quantum hardware is often dismissed as a distant theoretical problem for the 2030s.

In production security engineering, the migration timeline is governed by "Harvest Now, Decrypt Later" (HNDL) adversaries: hostile actors recording encrypted TLS traffic today to decrypt once cryptanalytically relevant quantum computers exist. If your data has a 10-year confidentiality lifecycle, you are already five years late.

The lattice-based finalists: ML-KEM and ML-DSA

NIST's post-quantum standardization process selected lattice-based cryptographic constructions based on the Module Learning With Errors (M-LWE) problem:

• ML-KEM (Kyber): Key Encapsulation Mechanism used for establishing shared symmetric session secrets.
• ML-DSA (Dilithium): Digital Signature Algorithm used for public-key authentication and x509 certificate chains.

Lattice problems cannot be efficiently solved by Shor's or Grover's quantum algorithms. However, security comes with a substantial payload size penalty.

// Rust: Inspecting Hybrid X25519 + ML-KEM-768 Public Key Sizes
pub struct KeyExchangePayload {
    pub classic_x25519: [u8; 32],      // 32 bytes (Standard ECC)
    pub pqc_ml_kem_768: [u8; 1184],    // 1,184 bytes (Post-Quantum)
}

// Total ClientHello KeyShare grows from ~32 bytes to >1.2 KB,
// risking TCP Initial Window (initcwnd) packet fragmentation.

The challenge of post-quantum cryptography is not mathematical security; it is network plumbing: accommodating kilobyte-scale public keys without triggering MTU packet fragmentation in legacy middleboxes.

The hybrid TLS 1.3 key exchange model

Because new post-quantum algorithms lack decades of real-world cryptanalysis, modern standards do not replace classical ECC outright. Instead, they deploy hybrid key exchanges: combining classical X25519 with ML-KEM-768.

The resulting shared secret is derived using HKDF over both outputs: \(\text{Secret} = \text{HKDF}(\text{SS}_{\text{X25519}} \mathbin{\Vert} \text{SS}_{\text{ML-KEM}})\). An attacker must break both mathematical problems simultaneously to compromise the connection.

Middlebox intolerance and fragmentation

A standard X25519 TLS 1.3 ClientHello fits within 500 bytes. Adding ML-KEM keys expands the packet beyond standard 1500-byte Ethernet MTUs, forcing IP fragmentation. Legacy corporate firewalls and middleboxes frequently drop fragmented UDP/TCP handshake packets, leading to silent connection timeouts.

Mitigating this requires tuning TCP initcwnd and implementing gradual fallback telemetry across production load balancers.

Implementing hybrid post-quantum TLS handshakes or auditing cryptographic agility? Send me a note.