Post-quantum migration

A cryptographically relevant quantum computer (CRQC) running Shor's algorithm would solve the integer factoring and discrete logarithm problems efficiently. That breaks RSA, finite-field Diffie-Hellman, ECDH (including X25519), ECDSA and EdDSA. Nobody has one today. The threat that matters now is harvest now, decrypt later (HNDL): an adversary records encrypted traffic today and decrypts it when a CRQC exists. Anything whose key exchange used only classical algorithms is exposed retroactively.

Symmetric crypto is only dented. Grover's algorithm gives a quadratic speed-up on brute force, which in theory halves the effective key length, and in practice is far worse than that for the attacker because the search does not parallelise well. AES-256 and SHA-256 are considered safe; AES-128 is still widely judged acceptable but AES-256 is the conservative choice for long-lived data.

Mosca's inequality turns this into a decision: let x be how long the data must stay secret, y how long your migration will take, and z how long until a CRQC exists. If x + y > z, you are already late. Medical records (x = decades) plus a five-year migration (y = 5) beat almost any estimate of z, which is why key exchange for long-lived data comes first.

NIST published the first three post-quantum standards in August 2024. FIPS 203, ML-KEM (module-lattice key encapsulation, from CRYSTALS-Kyber) replaces key exchange. FIPS 204, ML-DSA (from CRYSTALS-Dilithium) is the general-purpose signature. FIPS 205, SLH-DSA (from SPHINCS+) is a hash-based signature with very conservative security assumptions and large signatures. A KEM differs from Diffie-Hellman: one side publishes an encapsulation key, the other encapsulates a fresh random shared secret to it and sends the ciphertext, and the first side decapsulates.

Compute is not the problem: ML-KEM operations take tens of microseconds, comparable to or faster than X25519. Bytes are the problem. A hybrid ClientHello grows by about 1.2 KB and usually no longer fits in one packet. That broke some middleboxes and servers that assumed the ClientHello arrives in a single TCP segment, a class of bug catalogued at tldr.fail. Signatures are worse: a chain with ML-DSA-44 leaf and intermediate certificates, a CertificateVerify and two SCTs adds roughly 10 to 15 KB, enough to overflow a typical initial congestion window (10 segments, about 14 KB) and cost an extra round trip. That is why the web moved key exchange first and is still working on signatures.

The standardised hybrid group is X25519MLKEM768 (codepoint 0x11EC). The client share is the 1,184-byte ML-KEM-768 encapsulation key followed by its 32-byte X25519 key; the server returns a 1,088-byte ML-KEM ciphertext followed by its X25519 key. Both derive the ML-KEM shared secret and the X25519 shared secret, concatenate them (64 bytes) and feed the result into the normal TLS 1.3 key schedule. An attacker must break both to recover the session keys.

• Browsers: Chrome made X25519MLKEM768 the default in version 131 (November 2024), replacing the earlier X25519Kyber768Draft00 draft codepoint. Other major browsers have followed.
• Libraries: OpenSSL 3.5 (April 2025) ships ML-KEM, ML-DSA and SLH-DSA and offers X25519MLKEM768 by default; Go 1.24 enables it by default in crypto/tls; BoringSSL and rustls support it.
• SSH: OpenSSH 9.0 defaulted to the hybrid sntrup761x25519-sha512, and OpenSSH 10.0 made mlkem768x25519-sha256 the default.
• CDNs: major CDNs negotiate it at the edge, so browser to edge is often already hybrid. Edge to origin frequently is not.

# OpenSSL 3.5+: offer ONLY the hybrid group, so success proves the server supports it
openssl s_client -connect api.cyart.io:443 -servername api.cyart.io \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "negotiated"
# Negotiated TLS1.3 group: X25519MLKEM768

# A failure here ("handshake failure" / no shared group) means classical-only key exchange

# nginx linked against OpenSSL 3.5: prefer hybrid, keep classical fallbacks for old clients
ssl_protocols   TLSv1.2 TLSv1.3;
ssl_ecdh_curve  X25519MLKEM768:X25519:prime256v1;

Signatures are less urgent for HNDL because a forged signature needs a CRQC at the time of the attack; recorded signatures cannot be retroactively abused unless they still authorise something. The exception is anything verified far in the future: a firmware root burned into a device that ships for 15 years must be PQ before the device ships.

• Start from the CBOM: tag each asset with use (key exchange or signature), data lifetime and owner. Those three fields produce the migration order.
• Find the hidden RSA: wrapped DEKs, partner SFTP keys, SAML signing certs, HSM-held code-signing keys and hard-coded TLS configs on internal services.
• Test the network, not just the library: enable hybrid groups behind a flag and watch for handshake failures from middleboxes, old load balancers and proxies that break on large ClientHellos.
• Ask vendors for dates: your CDN, load balancers, HSMs, VPN concentrators and KMS. Many migrations are blocked on a box you do not control.