Post-quantum cryptography

Quantum computers use the rules of quantum physics to do some calculations in a completely different way from ordinary computers. Today’s machines are small and make many errors. None has publicly broken a real cryptographic key, and nobody knows when, or whether, a machine big enough to do so will exist. Still, the cryptography community decided years ago not to wait and see. Here is why, in calm terms.

Most of the cryptography in this handbook comes in two kinds.

• Public-key cryptography: the key pairs, key exchange and digital signatures from chapters 3 to 6. Today these use RSA and elliptic curves (ECDH, ECDSA, Ed25519). Their security rests on maths problems, factoring large numbers and computing discrete logarithms, that ordinary computers cannot solve in any useful time. A large quantum computer running Shor’s algorithm could solve them. For these algorithms, a big enough quantum computer means broken.
• Symmetric cryptography and hashes: AES and SHA-256 from chapters 1 and 5. The best known quantum attack, Grover’s algorithm, only speeds up a brute-force search, roughly halving the key’s strength in bits, and is very hard to run at scale. For these, a quantum computer means weakened, not broken. Keys and hashes of 256 bits keep a large safety margin.

So the work is to replace the public-key parts. That is what post-quantum cryptography (PQC) means: new public-key algorithms, based on different maths, that are believed to resist quantum computers. They run on ordinary computers and phones. You do not need a quantum computer to use them.

Why start before such a computer exists? Because of harvest now, decrypt later. Someone can record encrypted traffic today and store it. If the key exchange that protected it can be broken one day, the recording can be read then. Data that must stay secret for ten or twenty years, such as health records, state secrets and trade secrets, is already at risk if it travels with classical key exchange today. That is why key exchange moved first, and why it is already done in your browser.

Signatures are different. A forged signature needs a quantum computer at the moment of forging, so recording today’s signatures gives an attacker nothing. But some signing keys live for a very long time: root CAs, firmware signing keys in cars and routers, document signatures that must hold for decades. Those need a plan now, because changing them takes years.

What exactly does a quantum computer break?

Swipe sideways to see the whole diagram.

NIST’s draft transition report puts it plainly: its symmetric primitives that provide at least 128 bits of classical security are believed to meet its lowest post-quantum security category, so AES-128 is not suddenly unsafe (NIST IR 8547 initial public draft, section 4.1.3). Many organisations still choose AES-256 for data that must stay secret for decades, to keep a wide margin.

Forward secrecy does not solve the quantum problem. TLS 1.3 uses ephemeral (EC)DHE key exchange, so a server key stolen later cannot decrypt old sessions (chapter 15). But an attacker with a quantum computer would not need the server’s key. They would compute the session secret directly from the key shares they recorded. Only a post-quantum key exchange closes that gap.

Which new algorithms did NIST standardise?

NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024.

• ML-KEM (FIPS 203, from the CRYSTALS-Kyber design) is a key-encapsulation mechanism, or KEM. One side publishes an encapsulation key. The other side uses it to create a shared secret plus a ciphertext and sends back the ciphertext, which only the holder of the decapsulation key can open. It replaces ECDH for agreeing keys. Its security rests on hard problems over module lattices.
• ML-DSA (FIPS 204, from CRYSTALS-Dilithium) is a lattice-based signature algorithm. It is fast and is expected to be the general replacement for ECDSA and RSA signatures.
• SLH-DSA (FIPS 205, from SPHINCS+) is a hash-based signature algorithm. Its security rests only on the hash function, which makes it a conservative choice for long-lived roots and firmware. Its signatures are large and slow to make.

Two more are on the way. FN-DSA is a compact signature scheme based on Falcon (planned as FIPS 206 and not yet final). HQC is a second KEM, built on different maths so that it can serve as a backup to ML-KEM (selected for standardisation by NIST, 11 March 2025).

Why are post-quantum keys and signatures so big?

They are, and that matters more than speed. The sizes below come from the size tables in FIPS 203 (Table 3), FIPS 204 (Table 2) and FIPS 205 (Table 2), next to the classical algorithms they replace:

A TLS handshake carries several public keys and signatures: the leaf certificate’s key and the CA’s signature on it, the intermediate’s key and the root’s signature on it, and the server’s CertificateVerify signature. With ECDSA that is a few hundred bytes. With ML-DSA-44 it is close to 10 kilobytes. Bigger handshakes mean more round trips on slow links, and some old middleboxes choke on them.

How does hybrid key exchange work in TLS?

TLS 1.3 already lets the client offer key shares for several “groups”. A hybrid key exchange group combines a classical and a post-quantum algorithm in one share, so the connection stays safe as long as either of them holds. The general design is described in RFC 9954, and the groups browsers use are defined in RFC 10024. For X25519MLKEM768 (section 4):

1. The client’s key share is its ML-KEM-768 encapsulation key followed by its X25519 share: 1,216 bytes instead of 32.
2. The server encapsulates to the ML-KEM key and replies with the ML-KEM ciphertext followed by its own X25519 share: 1,120 bytes.
3. Both sides now hold two shared secrets of 32 bytes each. TLS feeds their concatenation into its normal key schedule, and the session keys are derived from it.

Swipe sideways to see the whole diagram.

Why hybrid rather than ML-KEM alone? ML-KEM is new, and new algorithms and their implementations sometimes have flaws that only show up after years of use. X25519 is well understood but not quantum-safe. Combining them means a flaw in either one alone does not expose the session. Today X25519MLKEM768 hybrid post-quantum key exchange is on by default in Chrome, Firefox and Apple's operating systems (since late 2024 in Chrome 131 and Firefox 132), so a large share of web traffic is already protected against harvest now, decrypt later. The certificates in those same connections are still classical, which is fine for now: a signature cannot be forged after the fact.

Why are post-quantum certificates harder?

Key exchange changed with a software update on both ends. Certificates involve the whole ecosystem: CAs, HSMs, root programs, Certificate Transparency logs, every client that validates chains, and every device with a trust store that is rarely updated.

The standards pieces are arriving. The X.509 algorithm identifiers for ML-DSA are in RFC 9881, with companion RFCs for SLH-DSA and ML-KEM. Recent versions of common libraries, such as OpenSSL 3.5 and later, implement ML-KEM, ML-DSA and SLH-DSA, so private PKIs can start testing. The public web is more careful: Publicly trusted TLS certificates still use classical signatures such as RSA and ECDSA; post-quantum signatures are not yet allowed in them. Rather than simply putting large ML-DSA signatures into today’s certificate chains, Chrome is working on a different design: Chrome plans a separate quantum-resistant root store built on Merkle Tree Certificates, and has no immediate plan to add post-quantum X.509 certificates to the Chrome Root Store (Google Security Blog).

For your own planning, sort signing keys by how long they must be trusted:

• Short-lived TLS certificates will follow the browsers and CAs. Automation (chapter 20) makes the switch a configuration change when the time comes.
• Private CAs for mutual TLS, devices and internal services can move on your own schedule, and you can test now.
• Roots, firmware and code signing keys, and long-term document signatures last for decades. These are the first signing keys to plan for, because a device sold today with a classical-only update key may still be in use when that key can no longer be trusted.

What is crypto-agility?

Crypto-agility is the ability to change algorithms without rebuilding your systems. It is not a product. It is a set of habits:

• Know what you use. Keep an inventory of algorithms, key sizes and libraries alongside your certificate inventory, and of which data must stay secret for how long.
• Configure, do not hard-code. Algorithms should be settings in libraries and services, not constants spread across code.
• Use protocols that negotiate. TLS 1.3 let browsers add hybrid key exchange without breaking older servers, because both sides agree on a group in the handshake.
• Automate certificates. If renewing every certificate is routine, replacing every certificate with a new algorithm is routine too.

What are the deadlines?

Nobody can name the year a quantum computer will break RSA. Governments therefore set planning dates based on how long migrations take:

• United States: NIST IR 8547 (initial public draft, November 2024): NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035. It is still a draft, but it shows the direction.
• European Union: the coordinated roadmap of 23 June 2025 says EU member states should start the transition by the end of 2026, finish it for high-risk use cases by the end of 2030 and complete as much as feasible by 2035.

These dates are about finishing a transition, not about when to start. Large organisations need several years just to find every place that uses RSA or elliptic curves.

What does my connection use today?

openssl s_client -brief shows the key exchange and the certificate’s signature type. With OpenSSL 3.2, which does not implement ML-KEM, the result is classical:

openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org -brief </dev/null

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Peer certificate: CN=letsencrypt.org
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits

From OpenSSL 3.5, the default key shares offer X25519MLKEM768 as well as X25519 (OpenSSL 3.5 release notes), so the same command against a server that supports it negotiates the hybrid group.

Which algorithms do my certificates use?

Inventory starts with reading what is there. For each certificate, record the key algorithm and the signature algorithm:

openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -E "Public Key Algorithm|NIST CURVE|Signature Algorithm" | sort -u

                NIST CURVE: P-256
            Public Key Algorithm: id-ecPublicKey
        Signature Algorithm: ecdsa-with-SHA384
    Signature Algorithm: ecdsa-with-SHA384

ECDSA on P-256 is a perfectly good choice today, and it is exactly the kind of entry your inventory should flag as “quantum-vulnerable, replace when the ecosystem is ready”. Paste certificates into the decoder to read the same fields:

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

How do I plan a migration?

1. Inventory every use of public-key cryptography: TLS endpoints, VPNs, SSH, code signing, document signing, device identities, HSMs and the libraries behind them.
2. Rank by data lifetime and key lifetime. Long-lived secrets in transit need post-quantum key exchange first. Long-lived signing keys need post-quantum signatures next.
3. Turn on hybrid key exchange where your servers, load balancers and libraries support it, and test that firewalls and proxies accept the larger ClientHello. Some older servers and middleboxes fail when the first handshake message no longer fits in one network packet.
4. Ask your vendors for their post-quantum roadmap: HSMs, CAs, VPNs, devices and cloud services.
5. Pilot post-quantum signatures in a private CA and measure handshake sizes and performance.
6. Build crypto-agility into everything new, so the next change is cheaper than this one.

Common mistakes

• “Quantum computers will break all encryption.” They threaten public-key algorithms. AES and SHA-2 are only weakened, and good key and hash sizes handle that.
• “We will have to replace AES.” No. Keep AES. Prefer 256-bit keys for secrets that must last for decades.
• “Post-quantum cryptography needs a quantum computer.” It runs on ordinary computers, phones and servers, and it is already in your browser.
• “We can wait until quantum computers exist.” Recorded traffic can be decrypted later, and migrations take years. Key exchange for long-lived secrets needs protection now.
• “Forward secrecy already protects us.” It protects old sessions against a stolen server key. It does not protect recorded key shares against a quantum attacker.
• “Hybrid is a weaker compromise.” A hybrid exchange stays secure as long as either of its parts holds. It is the cautious choice while new algorithms mature.

Check yourself

Check yourself

Which of these would a large quantum computer actually break?

1. AES-256 encryption
2. SHA-256 hashes
3. ECDH key exchange such as X25519

Show answer

Answer C ECDH key exchange such as X25519

What happened

ECDH falls to Shor's algorithm. AES and SHA-256 are only weakened by Grover's algorithm.

Why

Public-key algorithms rest on factoring and discrete logarithms, which Shor's algorithm solves. Symmetric algorithms only lose part of their margin.

The rule

Replace the public-key parts; keep AES and SHA-2 with good sizes.

Check yourself

Why did browsers switch key exchange to post-quantum before certificates?

1. Because of harvest now, decrypt later: recorded key exchanges could be broken later, but signatures cannot be forged after the fact
2. Because post-quantum signatures do not exist yet
3. Because certificates do not use public-key cryptography

Show answer

Answer A Because of harvest now, decrypt later: recorded key exchanges could be broken later, but signatures cannot be forged after the fact

What happened

Traffic recorded today could be decrypted later if its key exchange is broken.

Why

A forged signature needs a quantum computer at the time of the attack, so today's signatures are not at risk from recordings.

The rule

Protect key exchange first, then plan signatures by how long each key must be trusted.

Check yourself

A TLS connection uses X25519MLKEM768. What happens if a flaw is found in ML-KEM next year?

1. The session keys are exposed at once
2. The session is still protected by the X25519 part
3. The browser falls back to TLS 1.2

Show answer

Answer B The session is still protected by the X25519 part

What happened

The session secret combines both exchanges, so an attacker must break both.

Why

Hybrid key exchange is designed to stay secure if either component holds.

The rule

Use hybrid key exchange while post-quantum algorithms mature.

Go deeper

• FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA): the standards, with parameter sets and sizes.
• NIST IR 8547 (initial public draft): NIST’s proposed transition, including what happens to RSA, ECDSA and AES.
• EU coordinated implementation roadmap: the EU milestones and first steps.
• RFC 9954 and RFC 10024: hybrid key exchange in TLS 1.3 and the X25519MLKEM768 group.
• RFC 9881: ML-DSA in X.509 certificates.
• Google Security Blog: A new path for Kyber on the web: Chrome’s move from Kyber to ML-KEM.
• Google Security Blog: quantum-resistant certificates: Merkle Tree Certificates and Chrome’s plans.

In the gameLevel 26: The quantum stormObservatory, Keystone. In development

The crash course covers this chapter in lesson 10, Beyond the browser, and what comes next.