NIST Post-Quantum Cryptography Standards: ML-KEM, ML-DSA, SLH-DSA and FN-DSA Explained
The NIST post-quantum cryptography standards, finalised in August 2024, define the algorithms governments and industries are expected to adopt before cryptographically relevant quantum computers can break today's public-key infrastructure. This guide covers every standardised algorithm, explains the underlying mathematical mechanisms in plain terms, maps out the status of each standard, and traces real adoption across TLS, cloud services, and digital finance. Whether you are a developer, security architect, or informed investor, this is the reference you need to understand what the post-quantum transition actually involves.
Why NIST Ran a Post-Quantum Standardisation Process
Classical public-key cryptography, including RSA, ECDSA, and Diffie-Hellman, relies on mathematical problems that are computationally hard for conventional computers: integer factorisation and discrete logarithms. Peter Shor's 1994 algorithm demonstrated that a sufficiently powerful quantum computer could solve both problems in polynomial time, effectively rendering every certificate, wallet signature, and encrypted connection based on those primitives vulnerable.
NIST launched its Post-Quantum Cryptography (PQC) Standardisation Project in 2016, calling for algorithm submissions that could resist attacks from both classical and quantum adversaries. After three formal evaluation rounds and an additional round for signature schemes, NIST published four finalised standards in FIPS documents on 13 August 2024:
- FIPS 203 — ML-KEM (Module-Lattice Key Encapsulation Mechanism), formerly Kyber
- FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm), formerly Dilithium
- FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), formerly SPHINCS+
- FIPS 206 — FN-DSA (FFT over NTRU-Lattice Digital Signature Algorithm), formerly Falcon
A fifth algorithm, BIKE (a code-based KEM), remains under evaluation as a potential backup; HQC was also retained in 2024 for a fourth round. This article focuses on the four finalised FIPS standards.
---
ML-KEM (FIPS 203): The Primary Key Encapsulation Mechanism
What It Does
A Key Encapsulation Mechanism (KEM) allows two parties to establish a shared secret over an untrusted channel without transmitting the secret itself. The shared secret is then used to derive symmetric encryption keys (e.g. for AES-256). ML-KEM replaces the Diffie-Hellman and ECDH handshakes used in TLS, SSH, and similar protocols.
The Mathematical Foundation
ML-KEM is built on the Module Learning With Errors (MLWE) problem. In simple terms:
- A public matrix A and a secret vector s are combined with a small random error vector e: the public key is essentially A·s + e.
- Reconstructing s from the public key requires solving a system of equations where small, structured noise has been deliberately introduced.
- Even Shor's algorithm provides no meaningful advantage against MLWE. The best known quantum attacks still require exponential time.
The "module" prefix means the lattice is structured as a matrix of polynomial rings, which allows compact key sizes while retaining security.
Key Sizes and Performance
| Parameter Set | Security Level | Public Key | Ciphertext | Secret Key |
|---|---|---|---|---|
| ML-KEM-512 | NIST Level 1 (~AES-128) | 800 B | 768 B | 1,632 B |
| ML-KEM-768 | NIST Level 3 (~AES-192) | 1,184 B | 1,088 B | 2,400 B |
| ML-KEM-1024 | NIST Level 5 (~AES-256) | 1,568 B | 1,568 B | 3,168 B |
For comparison, an ECDH-256 public key is 64 bytes. ML-KEM keys are larger, but encapsulation and decapsulation run in microseconds on modern CPUs, making the bandwidth trade-off manageable for most protocols.
Adoption Status
- Google Chrome enabled ML-KEM-768 (as X25519MLKEM768) in TLS 1.3 handshakes from Chrome 131 (November 2024).
- Cloudflare rolled out hybrid X25519+ML-KEM on its edge network throughout 2024.
- AWS Key Management Service and Azure announced ML-KEM integration roadmaps in their post-quantum transition documentation.
- OpenSSL 3.x and BoringSSL both include ML-KEM support via the OQS (Open Quantum Safe) provider.
---
ML-DSA (FIPS 204): The Primary Digital Signature Standard
What It Does
Digital signatures authenticate the source and integrity of data: they are the mechanism behind SSL/TLS certificates, code-signing, email signing (S/MIME), and, critically, blockchain transaction authorisation. ML-DSA is designed as the general-purpose post-quantum replacement for ECDSA and RSA signatures.
The Mathematical Foundation
ML-DSA is based on the Module Short Integer Solution (MSIS) and MLWE problems, following the Fiat-Shamir with Aborts paradigm:
- The signer commits to a random polynomial vector and produces a challenge using a hash function.
- The response vector must be short (bounded norm). If it is not short enough after a signing attempt, the attempt is aborted and restarted with a fresh random commitment.
- Verification checks that the response vector is short and that a reconstructed commitment matches the original hash challenge.
The abort mechanism is what makes the scheme secure: an attacker who tries to forge a signature cannot predict when aborts occur, preventing leakage of the secret key.
Key Sizes and Performance
| Parameter Set | Security Level | Public Key | Signature | Secret Key |
|---|---|---|---|---|
| ML-DSA-44 | NIST Level 2 | 1,312 B | 2,420 B | 2,528 B |
| ML-DSA-65 | NIST Level 3 | 1,952 B | 3,293 B | 4,000 B |
| ML-DSA-87 | NIST Level 5 | 2,592 B | 4,595 B | 4,864 B |
For context, an ECDSA-256 signature is 64 bytes. ML-DSA signatures are 30 to 70 times larger, a meaningful consideration for high-throughput blockchains and constrained IoT devices.
Adoption Status
- CNSA 2.0 (the US National Security Agency's Commercial National Security Algorithm Suite) mandates ML-DSA for software and firmware signing by 2030 for National Security Systems.
- Major PKI vendors including DigiCert and Entrust have issued hybrid certificates combining ECDSA and ML-DSA for testing.
- ETSI and ISO working groups are integrating ML-DSA into revised standards for electronic signatures and long-term document archival.
---
SLH-DSA (FIPS 205): The Hash-Based Fallback Signature Scheme
What It Does
SLH-DSA provides a digital signature scheme whose security rests entirely on the collision resistance of hash functions rather than on lattice assumptions. This makes it a diversified fallback: if a structural weakness is discovered in lattice-based schemes, SLH-DSA offers an independent security basis.
The Mathematical Foundation
SLH-DSA is a stateless version of the XMSS and LMS hash-based signature families. It combines three data structures:
- WOTS+ (Winternitz One-Time Signatures): Each leaf in a Merkle tree is a one-time signature key derived from a hash chain.
- FORS (Forest of Random Subsets): A few-time signature scheme used to sign message digests.
- HT (Hypertree): A tree-of-trees structure that authenticates FORS public keys, removing the statefulness requirement of older hash-based schemes.
Because all security proofs reduce to standard hash-function properties, SLH-DSA has the most conservative security assumptions of the four standards.
Key Sizes and Performance Trade-offs
SLH-DSA offers multiple parameter sets trading signature size against signing speed:
| Parameter Set | Security Level | Signature Size | Signing Time (approx.) |
|---|---|---|---|
| SLH-DSA-SHAKE-128s | NIST Level 1 (small) | ~7,856 B | ~55 ms |
| SLH-DSA-SHAKE-128f | NIST Level 1 (fast) | ~17,088 B | ~1 ms |
| SLH-DSA-SHAKE-256s | NIST Level 5 (small) | ~29,792 B | ~450 ms |
| SLH-DSA-SHAKE-256f | NIST Level 5 (fast) | ~49,856 B | ~4 ms |
The "s" (small) variants produce the smallest signatures but are significantly slower. The "f" (fast) variants are suitable for applications that prioritise throughput. This makes SLH-DSA well-suited for code-signing and certificate authority operations where signing is infrequent and large signatures are acceptable, but less suited for high-frequency transaction signing.
---
FN-DSA (FIPS 206): The Compact Lattice Signature Scheme
What It Does
FN-DSA occupies a niche between ML-DSA and ECDSA: it produces significantly smaller signatures than ML-DSA while remaining lattice-based. This makes it attractive for environments where bandwidth is tightly constrained, such as embedded systems, IoT sensors, and smart cards.
The Mathematical Foundation
FN-DSA is built over NTRU lattices using Fast Fourier Transform (FFT) arithmetic, which is the origin of the "FFT over NTRU-Lattice" name. The scheme follows the GPV (Gentry-Peikert-Vaikuntanathan) hash-and-sign framework:
- The signer uses a trapdoor basis for an NTRU lattice to sample a short Gaussian vector close to the hash of the message.
- Verification checks that the vector is short and maps to the correct lattice point.
The Gaussian sampling step requires careful constant-time implementation to prevent timing side-channel attacks. This implementation complexity is one reason FN-DSA was designated as a supplemental standard rather than the primary signature standard, even though its signature sizes are attractive.
Key Sizes
| Parameter Set | Security Level | Public Key | Signature |
|---|---|---|---|
| FN-DSA-512 | NIST Level 1 | 897 B | 666 B |
| FN-DSA-1024 | NIST Level 5 | 1,793 B | 1,280 B |
FN-DSA-512 signatures at 666 bytes are roughly 10 times the size of ECDSA-256 but far smaller than ML-DSA equivalents, positioning FN-DSA as the preferred choice where signature compactness is the dominant constraint.
---
Comparing the Four NIST PQC Standards
| Standard | FIPS | Type | Primary Use Case | Security Basis | Relative Sig. Size |
|---|---|---|---|---|---|
| ML-KEM | FIPS 203 | KEM | Key exchange / TLS | Module LWE | N/A (not a signature) |
| ML-DSA | FIPS 204 | Signature | General-purpose signing | Module LWE / SIS | Large |
| SLH-DSA | FIPS 205 | Signature | Code-signing, archival | Hash functions only | Very large |
| FN-DSA | FIPS 206 | Signature | Constrained devices | NTRU lattices | Medium |
---
Migration Strategy: How Organisations Are Adopting PQC
Hybrid Mode as the Transition Approach
The current industry consensus is to run hybrid cryptographic schemes during the transition period, combining a classical algorithm (e.g. X25519 or ECDSA) with a post-quantum counterpart (e.g. ML-KEM or ML-DSA). A hybrid approach ensures that:
- Systems remain secure against classical attackers today (in case the new algorithms have undiscovered weaknesses).
- Systems are protected against quantum attackers if and when cryptographically relevant quantum computers emerge.
IETF RFC 9180 and draft standards for hybrid KEMs and hybrid signatures formalise this approach for TLS, HPKE, and certificate chains.
Crypto-Agility: Building for Algorithm Replacement
Beyond hybrid mode, NIST and security frameworks recommend crypto-agility: designing systems so that cryptographic primitives can be swapped without architectural overhauls. This means:
- Abstracting key management and signing operations behind configurable interfaces.
- Storing algorithm identifiers alongside keys and certificates.
- Automating certificate lifecycle management to enable rapid rotation if a vulnerability is discovered.
Relevance to Digital Asset Security
The threat to blockchain wallets is specific and serious: ECDSA private keys could be derived from public keys by a sufficiently powerful quantum computer running Shor's algorithm. Projects that have moved earliest to adopt NIST-standardised post-quantum cryptography will offer holders the strongest forward-security guarantees. BMIC.ai, for example, is a quantum-resistant wallet and token built on lattice-based cryptography aligned with the NIST PQC framework, designed explicitly to protect against this scenario.
Timeline Pressures
- 2025: NIST recommends organisations complete PQC inventory and begin hybrid deployments.
- 2030: CNSA 2.0 mandates full PQC adoption for US National Security Systems.
- 2035: NIST plans to deprecate RSA, ECDSA, and ECDH across federal use cases entirely.
The "harvest now, decrypt later" (HNDL) attack vector means adversaries may already be archiving encrypted traffic today, intending to decrypt it once quantum hardware matures. Long-lived secrets, including private keys and sensitive financial data, face retrospective exposure even before Q-day arrives.
---
Implementation Resources and Next Steps
Developers and security teams looking to begin PQC adoption have several mature resources:
- Open Quantum Safe (liboqs): A C library implementing all four NIST standards with language bindings for Python, Java, Go, and Rust.
- PQClean: A repository of clean, portable reference implementations of NIST PQC algorithms.
- NIST FIPS 203–206 documents: Freely available at csrc.nist.gov, with full algorithm specifications and test vectors.
- IETF PQC Working Group drafts: Cover integration into TLS 1.3, X.509, CMS, and SSH.
- NSA CNSA 2.0 FAQ: Provides timeline guidance for organisations operating National Security Systems.
Starting with a cryptographic inventory, identifying where RSA and ECDSA are in use, and piloting ML-KEM in TLS handshakes are the pragmatic first steps for most engineering teams.
Frequently Asked Questions
What is the difference between ML-KEM and ML-DSA?
ML-KEM (FIPS 203) is a Key Encapsulation Mechanism used to securely establish a shared secret between two parties, replacing Diffie-Hellman and ECDH in protocols like TLS. ML-DSA (FIPS 204) is a digital signature algorithm used to authenticate the source and integrity of data, replacing ECDSA and RSA signatures. Both are built on Module Lattice problems, but they serve entirely different cryptographic functions.
Are the NIST PQC standards finalised and safe to deploy now?
Yes. NIST published FIPS 203, 204, 205, and 206 as final standards in August 2024. They have been through multiple years of public cryptanalysis and are considered safe for deployment. The recommended approach is a hybrid mode that combines a classical algorithm with a post-quantum one, which protects against both classical and quantum adversaries and guards against any undiscovered weaknesses in the new schemes.
Why is SLH-DSA included if its signatures are so large?
SLH-DSA's security rests entirely on hash function collision resistance, which is a fundamentally different mathematical assumption from lattice problems. If a structural vulnerability were ever found in lattice-based schemes like ML-DSA or FN-DSA, SLH-DSA would remain secure. NIST included it as a conservative, diversified fallback. Its large signatures make it less suitable for high-frequency signing but acceptable for code-signing, certificate authorities, and long-term archival.
What is 'harvest now, decrypt later' and why does it matter?
Harvest now, decrypt later (HNDL) refers to adversaries capturing and storing encrypted data today with the intention of decrypting it once quantum computers are powerful enough to break classical encryption. This means even data encrypted with RSA or ECDH now could be exposed in the future. Organisations with long-lived sensitive data, including financial records, medical data, and private keys, face retrospective exposure and should prioritise PQC migration sooner rather than later.
When will NIST deprecate RSA and ECDSA?
NIST's current roadmap targets deprecation of RSA, ECDSA, and ECDH for federal use cases by approximately 2035. The NSA's CNSA 2.0 suite mandates full PQC adoption for National Security Systems by 2030. For non-federal organisations, timelines vary, but NIST recommends completing cryptographic inventories and beginning hybrid deployments no later than 2025.
Which NIST PQC algorithm is best for blockchain wallet security?
For wallet signature operations, ML-DSA (FIPS 204) is the general-purpose choice, offering well-studied security and good performance on standard hardware. FN-DSA (FIPS 206) is an alternative where signature compactness is critical, such as constrained embedded devices. SLH-DSA offers the most conservative security assumptions but produces much larger signatures, making it less practical for frequent on-chain transactions. Any of the three, deployed correctly, provides quantum resistance that ECDSA cannot offer.