Post-quantum cryptography

New public-key algorithms for key exchange and signatures that a future quantum computer can’t break, rolled out now, mostly alongside the old ones, because traffic recorded today can be decrypted later.

2 technologies on this page ↓

How it works

Almost all public-key cryptography in use rests on two hard problems: factoring large numbers (RSA) and discrete logarithms, including on elliptic curves (ECDH, ECDSA, Ed25519). Shor’s algorithm solves both in polynomial time on a large, error-corrected quantum computer, so once such a “cryptographically relevant” machine exists, it can work out private keys from public ones: forge signatures and certificates, and recover the session keys of any key exchange it has a recording of. Symmetric cryptography is far less exposed: NIST says AES and hashes with at least 128 bits of classical security already meet its lowest post-quantum security category. Post-quantum cryptography (PQC) replaces only the public-key parts, with algorithms that run on ordinary computers but rest on problems no known quantum algorithm solves efficiently. NIST published the first three standards on 13 August 2024: FIPS 203 ML-KEM (from CRYSTALS-Kyber), a key-encapsulation mechanism (KEM) built on module lattices; FIPS 204 ML-DSA (from CRYSTALS-Dilithium), a lattice-based signature; and FIPS 205 SLH-DSA (from SPHINCS+), a signature built only on hash functions, larger and slower but resting on the most conservative assumption. In March 2025 NIST picked HQC, a code-based KEM, as a backup to ML-KEM; its standard is still being written, as is FN-DSA, based on Falcon. A KEM isn’t a drop-in Diffie-Hellman: one side sends a public key, the other uses it to encapsulate a random secret and sends back a ciphertext that only the private key can decapsulate. Because the new algorithms have had far less scrutiny than RSA and elliptic curves, most deployments are hybrid. In TLS 1.3 the client’s key share carries an X25519 share and an ML-KEM-768 public key together (the group X25519MLKEM768, standardised as RFC 10024 in August 2026), and the session keys come from both secrets, so an attacker has to break both. Key exchange goes first because of “harvest now, decrypt later”: an adversary can record encrypted traffic today and decrypt it once the quantum computer arrives. A signature only has to resist forgery at the moment it is checked, so certificates can move later, apart from long-lived roots of trust and firmware signing keys that are hard to replace.

Think of it as

Changing the locks before a master key exists. Nobody can copy your keys yet, but a thief can photograph every sealed letter you send today and open them all the day the master key is cut, so you start with the letters and fit the new locks next to the old ones until you trust them.

Reach for it when

Data that must stay confidential for years, such as health, financial, legal or government records, crosses a network today: it is exposed to harvest-now-decrypt-later already
You run TLS endpoints, load balancers, VPNs or SSH: hybrid ML-KEM is a configuration or library upgrade away, and most current browsers already offer it
You issue long-lived roots of trust, firmware or code-signing keys that will still be trusted in the 2030s and can’t easily be rotated
You sell to US federal or national security customers, or to regulated sectors that follow NIST and NSA timelines

Think twice when

Replacing classical algorithms outright in a protocol people rely on today: deploy hybrids, so a flaw in the new algorithm or its implementation doesn’t leave you weaker than before
Rolling your own: use a vetted library with constant-time code (AWS-LC, BoringSSL, OpenSSL 3.5+, SymCrypt, Go’s standard library) rather than a research prototype
Moving every certificate to ML-DSA now, on the web: signatures are dozens of times larger, the handshake carries several of them, and browsers don’t yet accept post-quantum certificates from public certificate authorities
Re-encrypting data at rest out of fear: AES-256 and the keys a KMS wraps symmetrically are not what Shor’s algorithm breaks; check the public-key steps around them instead

A real example

A health insurer’s member API sits behind an AWS Application Load Balancer and calls a partner over mutual TLS. Records leaked in 2026 would still be sensitive in 2040, so the team starts with key exchange. It switches the ALB listener to one of the post-quantum TLS security policies, upgrades the partner client to OpenSSL 3.5, which offers X25519MLKEM768 by default, and watches the ALB connection logs to see how many handshakes now use ML-KEM. The first week shows 70% hybrid, the rest from old mobile clients and one monitoring probe on an older runtime. Certificates stay ECDSA for now, but the internal code-signing root, which must be trusted for 15 years, is reissued in AWS Private CA with ML-DSA.

Technologies

Specific products, and what each does differently.

liboqsOpen sourceThe Open Quantum Safe project’s C library of post-quantum key encapsulation and signature algorithms behind one API, from the NIST standards to candidates still under review, built for prototyping and research.mlkem-nativeOpen sourceA portable C90 implementation of ML-KEM (FIPS 203) with formally verified C and assembly, meant to be copied into other cryptographic libraries; AWS-LC, liboqs and, through AWS-LC, rustls use it.


liboqs	Open source	Open Quantum Safe, a Series of LF Projects (Post-Quantum Cryptography Alliance)PQCA project	MIT (some bundled algorithm implementations carry other open licences)	2026-10-28
mlkem-native	Open source	PQ Code Package (Post-Quantum Cryptography Alliance)PQCA project	Apache 2.0, ISC or MIT, at your choice	2026-10-28

What each provider calls it

AWS: Hybrid ML-KEM on KMS, ACM and Secrets Manager endpoints since April 2025, and on CloudFront, IAM and S3; opt-in post-quantum TLS policies for ALB and NLB since November 2025; ML-DSA signing keys in KMS since June 2025 and ML-DSA roots in Private CA; s2n-tls and the FIPS-validated AWS-LC library underneath
Google Cloud: Cloud KMS: ML-DSA, SLH-DSA and ML-KEM generally available since July 2026; load balancers negotiate X25519MLKEM768, on by default from October 2026 (deferrable to October 2027); Chrome has offered hybrid ML-KEM since version 131 in late 2024
Azure: SymCrypt, the library under Windows, Azure and Microsoft 365, implements ML-KEM, ML-DSA, LMS and XMSS; ML-KEM and ML-DSA are generally available in Windows 11, Windows Server 2025 and .NET 10 since November 2025, and SymCrypt-OpenSSL does hybrid TLS key exchange on Linux. Microsoft targets early adoption by 2029 and a full transition by 2033
Open source & others: OpenSSL 3.5+ (ML-KEM, ML-DSA, SLH-DSA; X25519MLKEM768 in the default key shares), BoringSSL, AWS-LC, Go 1.24+ crypto/tls, OpenSSH 10 (mlkem768x25519-sha256 by default); the PQCA’s liboqs for prototyping and mlkem-native and mldsa-native for verified implementations. Cloudflare offers hybrid key agreement to every visitor and, by default, to origins

The algorithms and what they weigh#

Sizes in bytes for the parameter sets most deployments use, with the classical algorithms they replace for comparison.

Algorithm	Job and basis	Public key	Ciphertext or signature	Status
ML-KEM-768	Key encapsulation; module lattices (CRYSTALS-Kyber)	1,184	1,088	FIPS 203, August 2024
ML-DSA-65	Signature; module lattices (CRYSTALS-Dilithium)	1,952	3,309	FIPS 204, August 2024
SLH-DSA-SHA2-128s	Signature; hash functions only (SPHINCS+)	32	7,856 (17,088 for the faster 128f)	FIPS 205, August 2024
HQC-1	Key encapsulation; error-correcting codes, a backup to ML-KEM	2,241	4,433	Selected March 2025; standard in development
Falcon-512 (FN-DSA)	Signature; NTRU lattices, compact but hard to implement safely	897	666 (padded)	Standard in development
X25519 / ECDSA P-256 / RSA-2048	What they replace; broken by Shor’s algorithm	32 / 64 / 256	32 / about 72 / 256	Deprecated after 2030, disallowed after 2035 (NIST)

A TLS handshake carries several signatures: the server’s, its certificate’s, the intermediate’s and usually two certificate-transparency timestamps. Swapping all of them for ML-DSA adds kilobytes, which is why the web moved key exchange first and is looking at new certificate designs such as Merkle Tree Certificates.

Deadlines that drive the migration#

Binding only on US government systems, but vendors and regulated industries plan against them.

NSA CNSA 2.0

2025 to 2033

For US national security systems: web browsers, servers and cloud services should support and prefer the CNSA 2.0 algorithms (ML-KEM-1024, ML-DSA-87, LMS, XMSS) from 2025 and use them exclusively by 2033, with software and firmware signing exclusive by 2030.

EO 14412 and OMB M-26-15

end of 2030 and 2031

A June 2026 executive order and OMB memo require US federal high value assets and high impact systems to use post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031, and federal systems to support TLS 1.3 by 2 January 2030.

NIST IR 8547

2030 and 2035

Finalised in October 2026: RSA, ECDSA, EdDSA, ECDH and finite-field Diffie-Hellman are deprecated after 2030 and disallowed in NIST standards after 2035, matching the 2035 goal set by National Security Memorandum 10 in 2022.

Cloud providers’ own targets

2029 to 2033

Cloudflare aims to be fully post-quantum secure, authentication included, by 2029; Microsoft aims for early adoption by 2029 and a complete transition of its products and services by 2033.

What it costs#

Key exchange is cheap. ML-KEM is fast on ordinary CPUs; the cost is size: an X25519MLKEM768 key share is about 1.2 KB from the client and 1.1 KB back, against 32 bytes each for X25519. The larger ClientHello no longer fits in a single packet, which exposed middleboxes and servers that assumed it would: Chrome shipped an enterprise policy to switch the hybrid off while vendors fixed them. Most current browsers now offer the hybrid, and Cloudflare reported in April 2026 that over 65% of human traffic to it was post-quantum encrypted.

Signatures are the hard part. ML-DSA-44 signatures are 2,420 bytes against 64 for Ed25519, and SLH-DSA, the conservative choice, starts at 7,856. That matters wherever many signatures travel together: TLS certificate chains, DNSSEC answers, certificate-transparency logs and constrained devices. Hybrid and composite certificates double the work again. Expect also to touch anything that hard-codes key or buffer sizes, HSMs that need firmware updates, and protocols with small packet limits.

The real work is finding the cryptography. Teams start with an inventory, or cryptographic bill of materials, of where public-key algorithms are used, including in third-party libraries and appliances, and prioritise data with a long confidentiality life. Making algorithms swappable through configuration, known as crypto-agility, pays off: HQC and FN-DSA are still coming, and Kyber’s and Dilithium’s pre-standard versions already had to be replaced once.

In code · bash

# OpenSSL 3.5+: does this server do hybrid post-quantum key exchange?
openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 -brief </dev/null
#   Protocol version: TLSv1.3
#   Signature type: ecdsa_secp256r1_sha256    <- the certificate is still classical
#   Negotiated TLS1.3 group: X25519MLKEM768
# (a server without ML-KEM fails here, because no other group was offered)

# A post-quantum signature, and what it costs
openssl genpkey -algorithm ML-DSA-65 -out mldsa.pem
openssl pkeyutl -sign -inkey mldsa.pem -in msg.txt -out sig.bin
wc -c < sig.bin    # 3309 bytes; an ECDSA P-256 signature is about 72

Often confused with

Network protocols Secrets management Confidential computing

Where it came from1994–2026

In 1994 Peter Shor showed that a quantum computer could factor integers and compute discrete logarithms in polynomial time, the two problems RSA and Diffie-Hellman rest on. Cryptographers had alternatives, such as McEliece’s code-based system from 1978 and hash-based signatures, but they were too big or too slow to replace RSA while quantum computers stayed theoretical. In 2016 NIST opened a public competition for quantum-resistant public-key algorithms, and the same year Google tried a hybrid of X25519 and the lattice scheme New Hope in Chrome Canary.

The competition ran in rounds for six years. In July 2022 NIST selected CRYSTALS-Kyber for key establishment and CRYSTALS-Dilithium, Falcon and SPHINCS+ for signatures. Cloudflare turned on hybrid post-quantum key agreement for all its websites that October, and Chrome made hybrid Kyber the default on desktop in version 124, in April 2024. The final standards, renamed ML-KEM, ML-DSA and SLH-DSA, came out on 13 August 2024 with small changes that made them incompatible with the drafts, so Chrome, Cloudflare and others moved from Kyber’s codepoint to X25519MLKEM768 within months.

Deployment then ran ahead of the paperwork. OpenSSH 10.0 and OpenSSL 3.5 made the hybrid the default in April 2025, AWS, Google Cloud and Microsoft added it to their endpoints, load balancers and libraries, and NIST chose HQC as a backup KEM in March 2025. The IETF published the hybrid TLS groups as RFC 10024 in August 2026, and in October 2026 NIST finalised the timeline that retires RSA and elliptic curves by 2035, as a June 2026 executive order pulled federal deadlines for the most sensitive systems forward to 2030 and 2031.

Why it’s built this way

Hybrid, not replacement: The new algorithms are young: SIKE, one of four key-establishment candidates still in NIST’s fourth round, was broken in 2022 by an attack that ran on an ordinary computer. Combining ML-KEM with X25519 keeps the connection at least as strong as before if either half fails.
Key exchange before signatures: Recorded traffic can be decrypted later, but a signature only has to hold when it is verified. Signatures are also much larger, so the web moved key agreement first.
Several mathematical families: ML-KEM and ML-DSA are both lattice schemes. SLH-DSA (hashes) and HQC (codes) are there in case a breakthrough against lattices takes out the primary standards.
A competition run in public: NIST let the world’s cryptographers attack every submission for six years, so the winners were chosen on years of open cryptanalysis rather than the say-so of one agency.

Timeline

1994
Peter Shor publishes polynomial-time quantum algorithms for factoring and discrete logarithms
2016
NIST opens its post-quantum standardisation process; Google tests hybrid New Hope in Chrome
2022
NIST selects Kyber, Dilithium, Falcon and SPHINCS+ (July); Cloudflare enables hybrid key agreement for all sites (October)
2024
Chrome 124 enables hybrid Kyber by default; FIPS 203, 204 and 205 published on 13 August
2025
HQC selected as backup KEM (March); OpenSSL 3.5 and OpenSSH 10.0 default to hybrid ML-KEM (April)
2026
Executive Order 14412 (June); RFC 10024 standardises X25519MLKEM768 (August); NIST IR 8547 final (October)

Sources24

Improve this page on GitHub