FIPS 203, 204 and 205, mapped to output

NIST published three post-quantum standards in August 2024: FIPS 203, FIPS 204 and FIPS 205. Between them they replace almost every asymmetric primitive in current enterprise use. This page sets out what each one actually specifies, where the engineering trade-offs sit, and — the part worth checking if you are buying from us — exactly which piece of AutoPQC output references which standard.

#What was published, and what was not

FIPS 203 specifies a key-encapsulation mechanism. FIPS 204 and FIPS 205 specify digital signature schemes. All three were finalised in August 2024 at the end of a NIST selection process that opened in 2016, and each derives from a submission to that process: ML-KEM from CRYSTALS-Kyber, ML-DSA from CRYSTALS-Dilithium, SLH-DSA from SPHINCS+.

Use the standardised names in documentation. Reviewers still recognise the submission names, and you will see both in vendor release notes, but a compliance artefact should cite the FIPS number and the parameter set. Definitions for each term are in the Lexicon.

• FIPS 203 — ML-KEM. Module-Lattice-Based Key-Encapsulation Mechanism. Establishes a shared secret between two parties. Replaces RSA key transport and elliptic-curve Diffie-Hellman key agreement.
• FIPS 204 — ML-DSA. Module-Lattice-Based Digital Signature Algorithm. Replaces RSA-PSS, RSA PKCS #1 v1.5 and ECDSA in most signing roles.
• FIPS 205 — SLH-DSA. Stateless Hash-Based Digital Signature Algorithm. A signature scheme whose security rests on hash functions rather than on lattices.

#FIPS 203: ML-KEM

ML-KEM rests on the hardness of the module learning-with-errors problem. It defines three parameter sets, each targeting a different claimed security category. Keys and ciphertexts are larger than their elliptic-curve equivalents but small enough that most protocols absorb them without redesign.

One integration error recurs often enough to name. ML-KEM is a key-encapsulation mechanism, not a public-key encryption scheme. It hands you a shared secret to feed into a key-derivation function; it does not encrypt your plaintext. Code that treats it as a drop-in for RSA-OAEP will not compile against a correct library, and code that forces the shapes to match usually gets the derivation wrong.

ML-KEM-768 is the common default for general transport security. ML-KEM-1024 is what the NSA selects for national security systems, which is covered in CNSA 2.0 and the federal timeline. Most estates deploy it first in hybrid mode alongside an existing elliptic-curve exchange; see Hybrid modes and keeping your rollback.

#FIPS 204: ML-DSA

ML-DSA also rests on module lattices, so it shares an assumption family with ML-KEM. That matters when you reason about correlated risk: a significant cryptanalytic result against module lattices would put pressure on your key establishment and your signatures at the same time. It is the main argument for keeping a hash-based signature scheme somewhere in the estate.

For scale: an ECDSA P-256 signature is 64 bytes raw, an RSA-2048 signature is 256 bytes. The smallest ML-DSA signature is roughly nine times an RSA-2048 signature and roughly thirty-eight times a raw P-256 one. In a TLS handshake carrying a full certificate chain, that multiplies across every certificate and every signature in the chain. Where the extra bytes push a handshake past a path MTU or a protocol field limit, the cost shows up as latency rather than as a failure, which is why we measure it rather than model it. See Proving the performance impact.

FIPS 204 defines both a hedged signing procedure, which mixes fresh randomness into each signature, and a deterministic one. It also defines a pre-hash variant, HashML-DSA, for cases where the signer cannot hold or stream the whole message. Pick deliberately: the hedged form is the default for good reasons, and a deterministic signer that leaks through a side channel is a different problem from the one you set out to solve.

#FIPS 205: SLH-DSA

SLH-DSA is built from Merkle hash trees over few-time signature schemes. Its security assumption is that the underlying hash function behaves as expected. That is the oldest and best-understood assumption in this set, which is the whole reason the standard exists alongside ML-DSA rather than being displaced by it.

The word stateless in the name is doing real work. NIST also standardised two stateful hash-based signature schemes in SP 800-208, LMS and XMSS. Those are sound, but a stateful signer that reuses a one-time key destroys its own security, and keeping that state correct across replicas, failovers, snapshots and restores is an operational hazard that has caught competent teams. SLH-DSA removes the state. You pay for it in signature size.

• Public keys are 32 to 64 bytes. They fit in one-time-programmable fuses, a bootloader constant, or a hardware root of trust where an ML-DSA key would not.
• Signing is slow relative to ML-DSA. The s variants trade signing time for a smaller signature; the f variants do the reverse.
• Verification is cheaper than signing but still far more expensive than ECDSA verification. Budget for it in anything that verifies at high rate.
• Choose the SHA2 or SHAKE instantiation according to what your hardware accelerates, not by preference.

#Choosing between ML-DSA and SLH-DSA

The decision is not about which scheme is better. It is about which failure mode you are willing to carry.

• Choose SLH-DSA where a signature is produced rarely, verified rarely, and has to survive for a long time: firmware images, boot chains, software release artefacts, offline root certificate authorities, archival signatures over records with decade-scale retention.
• Choose SLH-DSA where the verifier's public key must be tiny and immutable, burned into silicon or pinned in a bootloader that will never be updated.
• Choose SLH-DSA where you want assumption diversity. If a lattice result ever weakens ML-DSA, a hash-based root of trust is untouched by it, and a root of trust is the one thing you cannot re-sign remotely.
• Choose ML-DSA where volume, latency or bandwidth dominates: TLS and mTLS between services, token signing, message authentication at rate, anything inside a request path.
• Choose ML-DSA where the signature has to fit an existing protocol field or a certificate structure that other software parses without your involvement.

#Where each standard appears in AutoPQC output

A standards claim is only worth reading if you can trace it to a record. AutoPQC does not print three FIPS numbers on a cover page and stop there. Each reference attaches to something you can open, disagree with, and export.

Every one of those references is stamped with the method version that produced it, so a mapping does not silently change under an old report. That mechanism is described in How the method is versioned.