Research
NIST FIPS 203/204/205: The Complete Guide
14 min read
Who is NIST, and Why Do Their Standards Matter?
NIST is the National Institute of Standards and Technology, a non-regulatory agency within the U.S. Department of Commerce. NIST does not make laws or enforce regulations. What it does is publish technical standards that define how things should work, from the length of a meter to the algorithms that protect your bank account.
When it comes to cryptography, NIST's standards are the global reference. The U.S. government requires all federal agencies and their contractors to use NIST-approved cryptographic algorithms. But NIST's influence extends far beyond government. Financial institutions, healthcare organizations, technology companies, and critical infrastructure operators worldwide adopt NIST standards because they represent the consensus of the global cryptographic research community. When NIST says an algorithm is safe to use, it means that hundreds of the world's best mathematicians and computer scientists have tried to break it and failed.
FIPS stands for Federal Information Processing Standards. A FIPS publication is the highest level of standard NIST issues for information technology. When an algorithm receives a FIPS number, it means NIST has fully vetted it and considers it ready for production use in systems that protect sensitive information. AES (the encryption algorithm that protects nearly everything on the internet) is FIPS 197. SHA-2 (the hash function used in Bitcoin, TLS, and countless other systems) is FIPS 180-4. These are the standards the world runs on.
In August 2024, NIST published three new FIPS standards for post-quantum cryptography: FIPS 203, FIPS 204, and FIPS 205. A fourth, FIPS 206 (draft), is in draft. Together with the existing SP 800-208, these standards define the complete set of algorithms designed to protect information against attacks by both classical and quantum computers.
The Complete Standards at a Glance
| Standard | Algorithm | Purpose | Status | Math Family |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | Key encapsulation (key exchange) | Final (Aug 2024) | Lattice |
| FIPS 204 | ML-DSA | Digital signatures | Final (Aug 2024) | Lattice |
| FIPS 205 | SLH-DSA | Digital signatures (conservative) | Final (Aug 2024) | Hash-based |
| FIPS 206 (draft) | FN-DSA | Digital signatures (compact) | Draft | Lattice (NTRU) |
| SP 800-208 | LMS / XMSS | Stateful hash-based signatures | Final (Oct 2020) | Hash-based |
FIPS 203: ML-KEM (Key Encapsulation)
ML-KEM stands for Module-Lattice-Based Key Encapsulation Mechanism. Before NIST standardized it, it was known as CRYSTALS-Kyber. ML-KEM replaces the key exchange algorithms that quantum computers will break: RSA key exchange and Elliptic Curve Diffie-Hellman (ECDH).
To understand what ML-KEM does, think about how two people can agree on a secret in a room full of eavesdroppers. Imagine Alice wants to send Bob a secret message, but Eve is listening to every word they say. Alice cannot just whisper the encryption key to Bob, because Eve will hear it. Key encapsulation solves this problem: Alice and Bob can agree on a shared secret, in plain earshot of Eve, without Eve being able to figure out what the secret is.
The process works like this:
- Bob generates a key pair: a public key (which he shares openly) and a private key (which he keeps secret).
- Alice "encapsulates" a random secret using Bob's public key. This produces a ciphertext and the shared secret.
- Alice sends the ciphertext to Bob. Eve can see this ciphertext, but it is useless to her without Bob's private key.
- Bob "decapsulates" the ciphertext using his private key, recovering the same shared secret that Alice generated.
- Alice and Bob now share a secret key that they use for symmetric encryption (like AES-256-GCM) to protect their actual communications.
ML-KEM's security is based on the Module Learning With Errors (MLWE) problem. In simplified terms: take a lattice (a regular grid of points in high-dimensional space), add small random errors to it, and the resulting noisy data is computationally indistinguishable from truly random data. Extracting the original lattice structure from the noisy data is a problem that neither classical nor quantum computers can solve efficiently.
ML-KEM comes in three sizes:
- ML-KEM-512: NIST Level 1 (128-bit security). Public key: 800 bytes. Ciphertext: 768 bytes. Fast and compact.
- ML-KEM-768: NIST Level 3 (192-bit security). Public key: 1,184 bytes. Ciphertext: 1,088 bytes. The balanced option.
- ML-KEM-1024: NIST Level 5 (256-bit security). Public key: 1,568 bytes. Ciphertext: 1,568 bytes. Maximum security margin.
For comparison, a classical RSA-2048 public key is 256 bytes and its ciphertext is 256 bytes, but RSA is completely broken by quantum computers. ML-KEM keys are larger, but they actually provide security in the quantum era.
NIST designates ML-KEM as the primary recommendation for post-quantum key encapsulation. In March 2025, NIST also selected HQC (Hamming Quasi-Cyclic), a code-based KEM, as a backup algorithm built on different mathematical assumptions. HQC provides algorithm diversity: if a breakthrough compromises lattice-based cryptography, HQC remains secure because its security depends on error-correcting code problems instead. ML-KEM is faster and more compact; HQC is the insurance policy.
FIPS 204: ML-DSA (Digital Signatures)
ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. Before standardization, it was known as CRYSTALS-Dilithium. ML-DSA replaces the signature algorithms that quantum computers will break: RSA signatures and ECDSA.
Where ML-KEM solves the problem of agreeing on a shared secret, ML-DSA solves the problem of proving identity and data integrity. A digital signature proves that a specific person or organization created or approved a piece of data, and that the data has not been modified since it was signed.
Think of it as a mathematical notary stamp. When your phone checks a software update, it verifies a digital signature to ensure the update was actually published by the developer and was not modified by an attacker in transit. When your browser connects to your bank, it verifies a chain of digital signatures on the bank's certificate to confirm the site is genuine.
ML-DSA uses the same lattice mathematics as ML-KEM (the MLWE problem), but applied to the different problem of creating and verifying signatures. It comes in three security levels:
- ML-DSA-44: NIST Level 2 (128-bit security). Signature: 2,420 bytes. Public key: 1,312 bytes.
- ML-DSA-65: NIST Level 3 (192-bit security). Signature: 3,309 bytes. Public key: 1,952 bytes.
- ML-DSA-87: NIST Level 5 (256-bit security). Signature: 4,627 bytes. Public key: 2,592 bytes.
ML-DSA is NIST's primary recommendation for general-purpose post-quantum digital signatures. It is fast (thousands of signatures per second on modern hardware), reasonably compact, and well-understood. If you need a post-quantum signature algorithm and have no specific reason to choose otherwise, ML-DSA is the answer.
FIPS 205: SLH-DSA (Conservative Signatures)
SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. Before standardization, it was known as SPHINCS+. SLH-DSA does the same job as ML-DSA (digital signatures), but with a completely different approach to security.
While ML-DSA relies on lattice mathematics, SLH-DSA relies only on hash functions (SHA-256, SHA-512, SHAKE128, SHAKE256). Hash functions are the most studied and best-understood primitives in all of cryptography. They have been analyzed intensively for over 30 years. SLH-DSA's security proof boils down to: if the underlying hash function is secure, the signatures are unforgeable.
Why did NIST standardize SLH-DSA if ML-DSA already exists? Algorithm diversity. If a mathematical breakthrough compromises lattice problems, ML-DSA and ML-KEM would both be affected. SLH-DSA would be completely unaffected, because its security depends on different mathematics. SLH-DSA is the safety net.
The tradeoff is size. SLH-DSA signatures are much larger than ML-DSA signatures:
- SLH-DSA-128f: 17,088-byte signatures, but only 32-byte public keys
- SLH-DSA-192f: 35,664-byte signatures, but only 48-byte public keys
- SLH-DSA-256f: 49,856-byte signatures, but only 64-byte public keys
Each parameter set comes in "f" (fast signing, larger signatures) and "s" (slower signing, smaller signatures) variants. SLH-DSA is best suited for applications where the security guarantee matters more than signature size: long-term archival, root certificates, regulatory requirements for hash-based algorithms.
FIPS 206 (draft) (Draft): FN-DSA (Compact Signatures)
FN-DSA stands for FFT over NTRU-Lattice-Based Digital Signature Algorithm, formerly known as Falcon. FIPS 206 (draft) is currently in draft form, with finalization expected around 2027.
FN-DSA produces the smallest post-quantum signatures of any standardized algorithm. An FN-DSA-512 signature is about 666 bytes, compared to ML-DSA-44's 2,420 bytes. This 3.6x size advantage matters in bandwidth-constrained environments: TLS certificate chains, IoT devices, blockchain transactions.
The tradeoff is implementation complexity. FN-DSA's signing process requires high-precision floating-point arithmetic, and subtle implementation errors can leak secret key information through side-channel attacks. This is why NIST recommends ML-DSA as the default and positions FN-DSA as a secondary option for specific use cases where compact signatures are critical.
FN-DSA uses NTRU lattices, a different type of lattice from the module lattices used by ML-DSA and ML-KEM. This means FN-DSA provides algorithm diversity even within the lattice family.
SP 800-208: LMS and XMSS (Stateful Signatures)
NIST SP 800-208 standardizes two stateful hash-based signature schemes: LMS (Leighton-Micali Signatures, based on RFC 8554) and XMSS (eXtended Merkle Signature Scheme, based on RFC 8391). These were published in October 2020, predating the FIPS standards by nearly four years.
Like SLH-DSA, LMS and XMSS rely only on hash functions for their security. The difference is that LMS/XMSS are stateful: each signature uses up a "leaf" in a Merkle tree, and the key can only produce a fixed number of signatures determined at key creation time. Reusing a leaf (signing twice with the same one-time key) completely breaks security.
This statefulness limits LMS/XMSS to use cases where the number of signatures is bounded and predictable, such as firmware signing, code signing, and bootloader verification. The NSA's CNSA 2.0 suite specifically requires LMS or XMSS for these applications.
The advantage of statefulness is simplicity. LMS has a shorter, simpler security proof than SLH-DSA and produces smaller signatures (2.5-5 KB vs 17-50 KB for SLH-DSA). If you can manage the state tracking requirement, LMS gives you hash-only security with less overhead.
How These Standards Relate to Each Other
The five standards form a complete toolkit, covering different needs with different tradeoffs:
| Need | Primary Standard | Backup / Alternative |
|---|---|---|
| Key exchange / encryption | FIPS 203 (ML-KEM, lattice) | HQC (code-based, selected March 2025) |
| General-purpose signatures | FIPS 204 (ML-DSA, lattice) | FIPS 205 (SLH-DSA, hash-based) |
| Compact signatures | FIPS 206 (draft) draft (FN-DSA, NTRU lattice) | ML-DSA (if size is less critical) |
| Firmware / code signing | SP 800-208 (LMS/XMSS, hash-based) | ML-DSA (if statefulness is unacceptable) |
The design is deliberate: NIST built the portfolio across three mathematical families (lattice, hash-based, code-based) so that no single mathematical breakthrough can compromise everything. Each pair of primary/backup standards relies on independent math, providing genuine defense-in-depth at the standards level.
NIST Security Levels Explained
NIST defines five security levels for post-quantum algorithms, numbered 1 through 5. Each level corresponds to the difficulty of breaking the algorithm, measured against a well-known benchmark:
- Level 1: At least as hard to break as AES-128. This is the minimum for general commercial use.
- Level 2: At least as hard to break as SHA-256 collision resistance.
- Level 3: At least as hard to break as AES-192.
- Level 4: At least as hard to break as SHA-384 collision resistance.
- Level 5: At least as hard to break as AES-256. This is what governments require for top-secret information.
Each algorithm in the portfolio is available at multiple levels, allowing organizations to choose the security margin appropriate for their needs. Level 1 is adequate for most commercial applications. Level 5 provides the maximum margin for the most sensitive use cases. Higher levels mean larger keys and signatures, so there is always a tradeoff between security margin and efficiency.
The Eight-Year Process: Why It Took So Long
NIST launched the Post-Quantum Cryptography Standardization Process in December 2016 with a public call for proposals. They received 82 complete submissions from research teams around the world. What followed was a multi-round public evaluation that took eight years:
- Round 1 (2017-2019): 69 submissions accepted for evaluation. The global cryptographic community analyzed each submission for security weaknesses, implementation flaws, and performance issues. 26 advanced to Round 2.
- Round 2 (2019-2020): Deeper analysis of the 26 remaining candidates. 15 advanced (7 finalists + 8 alternates) to Round 3.
- Round 3 (2020-2022): Intensive scrutiny of the finalists. In July 2022, NIST selected four algorithms for standardization: CRYSTALS-Kyber (now ML-KEM), CRYSTALS-Dilithium (now ML-DSA), SPHINCS+ (now SLH-DSA), and Falcon (now FN-DSA).
- Round 4 (2022-2025): A separate track evaluated additional KEM candidates for algorithm diversity. HQC was selected in March 2025.
- Standardization (2024): FIPS 203, 204, and 205 published in August 2024. FIPS 206 (draft) in draft.
This eight-year timeline is not bureaucratic delay; it is how cryptographic standards should be developed. Rushing a cryptographic standard into production without sufficient public analysis is how you end up with Dual EC DRBG (an NSA-compromised random number generator that was tragically standardized too quickly). NIST's process gives the global research community time to find flaws before the algorithms are deployed in systems that protect billions of people.
What About AES and SHA? Are They Quantum-Safe?
AES is quantum-safe. Grover's quantum search algorithm can theoretically speed up brute-force attacks against AES, but only by a square-root factor. AES-256 drops from 256-bit security to roughly 128-bit security against a quantum attacker, which is still extremely strong. AES-128 would drop to about 64-bit security, which is marginal, so organizations should prefer AES-256 going forward.
SHA-256 and SHA-3 are quantum-safe. Hash functions are affected by Grover's algorithm in a similar way: collision resistance drops by a cube-root factor, and pre-image resistance drops by a square-root factor. SHA-256 retains about 128 bits of collision resistance against quantum computers, which is adequate. SHA-3 is in the same position.
The quantum threat is specifically to public-key cryptography: the algorithms used for key exchange (RSA, ECDH) and digital signatures (RSA, ECDSA, EdDSA). These algorithms rely on math problems (integer factoring, discrete logarithms) that Shor's algorithm solves efficiently. Symmetric algorithms (AES) and hash functions (SHA-2, SHA-3) are not based on these problems and are not vulnerable to Shor's algorithm.
This is why the new FIPS standards replace only the public-key components. ML-KEM replaces RSA/ECDH for key exchange. ML-DSA replaces RSA/ECDSA for signatures. AES stays as the symmetric encryption algorithm. The new standards protect the key exchange, and AES protects the data.
Compliance and Migration Timelines
The NSA's CNSA 2.0 guidance sets the following deadlines for U.S. national security systems:
- 2025: Begin deploying PQC for firmware and software signing (LMS/XMSS).
- 2030: Stop using RSA and ECDH for key establishment. Switch to ML-KEM or approved PQC alternatives.
- 2033: Stop using RSA and ECDSA for digital signatures. Switch to ML-DSA, SLH-DSA, or approved PQC alternatives.
- 2035: All national security systems must use post-quantum cryptography exclusively.
These deadlines apply to government and defense systems, but the private sector has an even more urgent reason to migrate: harvest-now, decrypt-later attacks. Adversaries are recording encrypted communications today, storing them, and waiting for quantum computers to become powerful enough to decrypt them. If your data needs to remain confidential for 10, 20, or 30 years, the migration deadline is not 2035. It is now.
Healthcare records, financial data, trade secrets, legal communications, and personal data all have long confidentiality requirements. A patient's medical record encrypted with RSA today could be decrypted by a quantum computer in 2035, exposing private health information. The time to migrate is before the data is captured, not after.
Sources
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), August 2024
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA), August 2024
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA), August 2024
- NIST FIPS 206 (draft) (Initial Public Draft): FN-DSA
- NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes, October 2020
- NSA CNSA 2.0: Commercial National Security Algorithm Suite 2.0, September 2022
- NIST Post-Quantum Cryptography Project Page
Related Articles
- NIST Post-Quantum Cryptography Timeline: 2016-2026
- ML-KEM: Future of Key Encapsulation
- ML-DSA vs SLH-DSA: Which to Choose
- How to Implement PQC in Your Organization
NIST-Compliant Encryption
QNSQY implements all three FIPS standards: ML-KEM, ML-DSA, and SLH-DSA.
Originally published at quantumsequrity.com.