Why Hybrid Key Exchange, Not Pure Post-Quantum
ML-KEM has been through eight years of public cryptanalysis and is now a final NIST standard, but it is still a comparatively young algorithm family next to elliptic-curve Diffie-Hellman, which has stood since the 1980s. Real-world TLS 1.3 deployments — including major browsers and CDNs shipping PQC support today — don't switch straight to pure ML-KEM. They run a hybrid key exchange: both a classical algorithm and a post-quantum algorithm run independently, and their outputs are combined into a single session key. The security argument is simple — the combined key is only as weak as its strongest half. If a future mathematical attack ever broke ML-KEM, the classical X25519 secret would still protect the session against any adversary without a quantum computer. If a quantum computer ever broke X25519, the ML-KEM secret would still protect the session against it.
How the Combiner Works
This simulator uses a simple SHA-256 concatenation combiner: sessionKey = SHA-256(classicalSecret || pqcSecret). It demonstrates the core idea clearly, but production systems use a formally specified KDF instead — for example, IETF's hybrid key exchange drafts for TLS 1.3 specify precise input ordering and a proper HKDF construction, since the exact combiner matters for the security proof. Standardized hybrid groups already in use include X25519Kyber768 (X25519MLKEM768 post-finalization) and SecP256r1MLKEM768.
| Component | Basis | Breaks if... |
|---|---|---|
| X25519 (classical) | Elliptic curve discrete log | A large-scale quantum computer runs Shor's algorithm |
| ML-KEM (post-quantum) | Module lattice problems | An unforeseen classical or quantum mathematical attack on lattices |
| Hybrid combined key | Both of the above | Both algorithms are broken simultaneously — the actual goal of hybrid mode |
Curious where HQC fits in as a second, structurally independent PQC algorithm? See the HQC tool and the PQC Standards Tracker.