The world's most rigorous public cryptographic competition ran for eight years and produced the standards now replacing RSA and ECC across the global internet.
From the 2016 call for proposals to the 2024 final standards. Eight years of open public cryptanalysis produced the most thoroughly vetted public-key algorithms in cryptographic history.
December 2016
Call for Proposals
NIST formally invites cryptographers worldwide to submit quantum-resistant public-key algorithms for evaluation. 82 submissions arrive.
November 2017
Round 1 Begins
69 submissions accepted for evaluation. Public cryptanalysis begins; several candidates broken within months.
January 2019
Round 2: 26 Candidates Advance
After 14 months of cryptanalysis, the field is narrowed. Diversity across mathematical families is preserved deliberately.
July 2020
Round 3: 7 Finalists + 8 Alternates
CRYSTALS-Kyber, CRYSTALS-Dilithium, Falcon, SPHINCS+, Classic McEliece among others. SIKE included.
July 2022
First Selections Announced
CRYSTALS-Kyber selected for key encapsulation. CRYSTALS-Dilithium, Falcon, and SPHINCS+ selected for digital signatures. Days later, SIKE — a finalist — is broken by classical attack in under an hour on a laptop. New cryptography demands sustained scrutiny.
September 2022
Additional Signatures Call
NIST opens a parallel competition for non-lattice signature alternatives to ensure cryptographic diversity. 40 submissions received.
August 2024
First Standards Finalised
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) published as final federal standards. Production deployment can begin. Apple, Signal, Google, AWS already shipping pre-standard versions.
March 2025
HQC Selected as Backup KEM
NIST announces HQC, a code-based key-encapsulation mechanism, as a backup to ML-KEM in case lattice assumptions are later weakened. Cryptographic diversity policy in action.
2025 onward
FIPS 206 (Falcon) & Additional Signatures
FN-DSA (Falcon) draft expected as FIPS 206. The additional-signatures Round 2 continues with candidates from hash-based, code-based, multivariate, and MPC-in-the-head families.
02 · Foundations
The Five Mathematical Families
Post-quantum cryptography draws from five distinct mathematical foundations. Diversity matters: if one family is broken, others remain available.
◈ LATTICE
Lattice-Based
Primary Choice
Hardness of finding short vectors in high-dimensional lattices. Best balance of speed, key size, and security. Foundation of ML-KEM, ML-DSA, and Falcon. Based on Learning With Errors (LWE) and NTRU lattice problems.
ML-KEM · ML-DSA · FN-DSA
⬡ HASH
Hash-Based
Most Conservative
Security rests only on the hash function being collision-resistant — the most well-understood assumption in cryptography. Large signatures, slow signing, but maximally trustworthy fallback. Used in SLH-DSA, XMSS, LMS.
SLH-DSA · XMSS · LMS
∎ CODE
Code-Based
Mature Backup
Decoding random linear codes — a problem studied since 1978. McEliece is the oldest unbroken public-key system. Very large public keys but proven resistance. HQC chosen as NIST backup KEM.
Classic McEliece · HQC · BIKE
∞ ISOGENY
Isogeny-Based
Eliminated · Cautionary
Mappings between elliptic curves. SIKE reached NIST Round 4 then was broken by Castryck and Decru in 2022 — in under an hour on a laptop. A reminder that new mathematical assumptions require sustained cryptanalysis before deployment.
SIKE (broken) · CSIDH
▲ MULTI
Multivariate
Largely Eliminated
Systems of nonlinear polynomial equations over finite fields. Rainbow, a finalist, was broken in 2022. The family has struggled to produce surviving candidates. Some research interest remains.
Rainbow (broken)
◆ MPC
Symmetric / MPC-in-the-Head
Emerging
Signatures built from symmetric primitives and zero-knowledge proofs. Picnic, SDitH, and others. Slow but rely only on hash and symmetric assumptions. Under evaluation in NIST's additional signatures round.
Picnic · SDitH
03 · The Algorithms
The Standardised Algorithms
Five algorithms have completed or are completing NIST standardisation. Each has a specific role; selection depends on use case, performance constraints, and risk tolerance.
ML-KEM (CRYSTALS-Kyber)
FIPS 203 · Module-Lattice KEM
The replacement for RSA and ECDH in key exchange. The most consequential PQC algorithm currently shipping.
Family
Lattice (Module-LWE)
Public Key Size
800–1,568 bytes
Ciphertext Size
768–1,568 bytes
ML-KEM provides three security levels: ML-KEM-512 (AES-128 equivalent), ML-KEM-768 (AES-192 equivalent, the recommended default), and ML-KEM-1024 (AES-256 equivalent). Already deployed in Apple iMessage PQ3, Signal PQXDH, Chrome's hybrid TLS, AWS KMS, and Cloudflare's edge.
Strengths
Fast operations on modern CPUs. Small enough for TLS without major bandwidth penalty. Survived eight years of intense cryptanalysis.
Trade-offs
Public keys ~3× larger than RSA-2048. Lattice security assumptions are newer than RSA's factoring assumption.
ML-DSA (CRYSTALS-Dilithium)
FIPS 204 · Module-Lattice Signature
The general-purpose replacement for RSA and ECDSA signatures. The default choice for code signing, certificates, and authentication.
Family
Lattice (Module-LWE)
Public Key Size
1,312–2,592 bytes
Signature Size
2,420–4,595 bytes
Three parameter sets: ML-DSA-44, ML-DSA-65, ML-DSA-87 (recommended for high security). Designed for easier implementation than Falcon, avoiding floating-point arithmetic and side-channel pitfalls. Used in Cloudflare experiments and forthcoming TLS deployments.
Strengths
Constant-time implementation is straightforward. Fast signing and verification. Strong implementation track record.
Trade-offs
Signatures ~40× larger than ECDSA. Significant TLS handshake bandwidth impact at scale.
SLH-DSA (SPHINCS+)
FIPS 205 · Stateless Hash Signature
The conservative fallback signature. Security depends only on hash function security — the most well-understood assumption in cryptography.
Family
Hash-Based (Stateless)
Public Key Size
32–64 bytes
Signature Size
7,856–49,856 bytes
Available in "fast" and "small" variants at three security levels. Slow and large signatures make it impractical for high-throughput use, but its security rests on SHA-2 or SHAKE — no novel mathematical assumptions. The algorithm to deploy when lattice assumptions are too risky.
Strengths
Most conservative security assumption available. Decades of confidence in underlying hash primitives. Tiny public keys.
Trade-offs
Enormous signatures (up to 49 KB). Slow signing. Unsuitable for high-volume TLS or constrained devices.
FN-DSA (Falcon)
FIPS 206 Draft · NTRU Lattice Signature
The compact signature option. Optimised for bandwidth-constrained applications where signature size matters more than implementation simplicity.
Family
Lattice (NTRU)
Public Key Size
897–1,793 bytes
Signature Size
666–1,280 bytes
The smallest post-quantum signature available. Particularly attractive for TLS certificates, blockchain applications, and IoT. However, the signing algorithm requires floating-point arithmetic — a substantial implementation risk for side-channel attacks. Most deployments will favour ML-DSA over Falcon unless signature size is critical.
Strengths
Smallest PQC signatures. Best fit for high-volume signing where bandwidth costs accumulate.
Trade-offs
Floating-point signing is hard to implement securely. Significant side-channel risk. Patent disclosures complicate adoption.
HQC (Hamming Quasi-Cyclic)
Selected March 2025 · Code-Based KEM
The diversity backup for ML-KEM. If lattice assumptions are weakened, HQC provides an independent fallback based on different mathematics.
Family
Code-Based (Quasi-Cyclic)
Public Key Size
2,249–7,245 bytes
Ciphertext Size
4,481–14,469 bytes
Selected by NIST in March 2025 as a backup KEM to be standardised alongside ML-KEM. Based on the well-studied problem of decoding random linear codes — a fundamentally different assumption from lattices. Larger than ML-KEM but provides cryptographic diversity insurance.
Strengths
Independent security foundation from lattice algorithms. Hedge against future cryptanalysis of lattices.
Trade-offs
3–10× larger keys and ciphertexts than ML-KEM. Slower operations. Standardisation document not yet final.
Classic McEliece
Round 4 Finalist · Code-Based KEM
The conservative code-based KEM with 45 years of cryptanalytic history. Considered for niche high-assurance use despite enormous key sizes.
Family
Code-Based (Goppa)
Public Key Size
261 KB – 1.36 MB
Ciphertext Size
128–240 bytes
Designed in 1978 and never broken. The longest-standing public-key system in existence. Massive public keys make it impractical for TLS but viable for static key distribution in high-assurance environments (defence, long-term archive encryption). Not yet a final NIST standard but remains under evaluation.
Strengths
Most mature post-quantum primitive. Tiny ciphertexts. Exceptional confidence in security.
Trade-offs
Megabyte-scale public keys disqualify it from most applications. Slow key generation.
04 · Specialised Use
Stateful Hash Signatures: XMSS & LMS
A specialised category of hash-based signatures already standardised by NIST in SP 800-208, designed for environments where signing state can be reliably managed.
XMSS (Extended Merkle Signature Scheme) and LMS (Leighton-Micali Signatures) provide quantum-resistant signatures with the strongest possible security assumption — only that the underlying hash function is secure. Unlike SLH-DSA, they are stateful: the signer must reliably track which one-time keys have been used. Reusing a key catastrophically breaks the scheme.
This restriction makes them unsuitable for general-purpose use, but they are well-suited to firmware signing, secure boot, and code signing — applications where signature generation is centralised, infrequent, and auditable. The NSA's CNSA 2.0 explicitly approves LMS and XMSS for software and firmware signing. Several semiconductor vendors are already implementing XMSS in hardware roots of trust.
05 · Trade-offs
Performance & Operational Impact
Post-quantum algorithms are larger and, in some cases, slower than classical ones. The practical impact on TLS, certificates, and embedded systems is real but manageable.
Algorithm
Type
Public Key
Signature / Ciphertext
vs Classical
RSA-2048
Classical KEX / Sig
256 B
256 B
Baseline
ECDSA P-256
Classical Signature
32 B
64 B
Baseline
ML-KEM-768
PQC KEM
1,184 B
1,088 B
~4× larger
ML-DSA-65
PQC Signature
1,952 B
3,309 B
~50× larger
FN-DSA-512
PQC Signature
897 B
666 B
~10× larger
SLH-DSA-128f
PQC Signature
32 B
17,088 B
~260× larger
HQC-128
PQC KEM
2,249 B
4,481 B
~17× larger
Classic McEliece
PQC KEM
261,120 B
128 B
~1000× larger key
What this means operationally: A hybrid TLS handshake with ML-KEM and ML-DSA adds roughly 5–10 KB to the initial connection — measurable in mobile and IoT but invisible on desktop and server-to-server links. Cloudflare's production measurements show median TLS handshake time increasing by less than 5%. The cost is real but well below the threshold of user-noticeable.
The genuine pain points are code signing (larger signatures bloat firmware images), blockchain applications (transaction sizes balloon), and constrained IoT devices (memory and energy budgets are tight). These are solvable engineering problems but require deliberate planning.
We work with engineering and security teams to select the right NIST algorithms for each part of your cryptographic estate — TLS, signing, identity, archive, embedded.