Post-Quantum

A sufficiently large quantum computer would break the asymmetric cryptography that secures nearly all of today’s internet: RSA, Diffie-Hellman, and elliptic-curve keys would fall. That machine does not exist yet, but the migration to post-quantum cryptography (PQC) is already underway, because encrypted data captured today can be stored and decrypted the day the hardware arrives. This page explains what breaks, what replaces it, and what you can do now.

Why This Matters

In 2024 NIST finalized the first PQC standards, and browsers and cloud providers have already begun deploying them in TLS. This is not a distant academic concern: it is an active migration you will encounter in real systems within the span of your career. Understanding the shape of the threat lets you prioritize which secrets need protecting first.

Shor vs Grover: What Actually Breaks

Two quantum algorithms drive the threat, and they hit cryptography very differently.

Algorithm	Target	Effect	Response
Shor’s algorithm	Factoring and discrete log (RSA, DH, ECC)	Broken entirely; keys recoverable in polynomial time	Replace with PQC algorithms
Grover’s algorithm	Symmetric ciphers and hashes (AES, SHA)	Halves effective security (128-bit becomes ~64)	Double key sizes (AES-256, SHA-384)

The headline: asymmetric cryptography is broken, symmetric cryptography is merely weakened. AES-256 and SHA-384 remain secure against a quantum adversary; the crisis is in key exchange and signatures, which rely on the hard problems Shor solves.

The NIST PQC Algorithms

NIST standardized replacements built on math problems (structured lattices) believed hard even for quantum computers.

Standard	Name	Replaces	Role
FIPS 203	ML-KEM (formerly Kyber)	ECDH, RSA key transport	Key encapsulation (establishing a shared secret)
FIPS 204	ML-DSA (formerly Dilithium)	RSA/ECDSA signatures	Digital signatures
FIPS 205	SLH-DSA (formerly SPHINCS+)	Signatures (hash-based, conservative)	Signatures with different security assumptions

ML-KEM handles the “agree on a secret” job that ECDHE does in a TLS handshake; ML-DSA handles signing certificates and messages. The tradeoff is size: PQC keys and signatures are much larger than their elliptic-curve counterparts, which affects handshake bandwidth.

Harvest Now, Decrypt Later

The reason to act before quantum computers exist is a passive attack: an adversary records encrypted traffic today and stores it, then decrypts it once a quantum computer is available. Any secret with a long confidentiality lifetime, medical records, state secrets, long-term credentials, is already at risk even though the decryption happens years later. This is why key exchange is migrating first: it protects confidentiality of data in transit retroactively.

Hybrid Deployments Today

The industry is not betting everything on new algorithms immediately. The pragmatic approach is hybrid key exchange: run a classical algorithm (X25519) and a post-quantum one (ML-KEM) together, and combine both shared secrets. The connection stays secure if either algorithm holds, hedging against both quantum attacks and undiscovered flaws in the young PQC schemes.

cd ~/crypto-lab
# Check whether your OpenSSL build advertises a hybrid PQC group
openssl list -kem-algorithms 2>/dev/null | grep -i -E "mlkem|kyber" || echo "no PQC KEM in this build"

Expected output:

  X25519MLKEM768 @ default
  MLKEM768 @ default

If your build lists X25519MLKEM768, it can negotiate a hybrid post-quantum key exchange in TLS 1.3; older builds print the fallback message and need an upgrade. This connects directly to the sibling TLS Handshake page: the key-share step is exactly where PQC is being deployed.

Practical Guidance

1. Inventory long-lived secrets now; anything that must stay confidential for a decade is already exposed to harvest-now-decrypt-later.
2. Prefer AES-256 and SHA-384 for symmetric and hashing needs so Grover’s algorithm does not force a later migration.
3. Enable hybrid key exchange (X25519 plus ML-KEM) where your TLS stack supports it, so you get protection without betting solely on new algorithms.
4. Track the NIST standards (ML-KEM, ML-DSA, SLH-DSA) and your vendors’ PQC roadmaps rather than rolling your own PQC.
5. Plan for larger keys and signatures in protocol and storage design, since PQC artifacts are substantially bigger than elliptic-curve ones.