FIPS 204 is the NIST standard for ML-DSA — the Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium and finalized on 13 August 2024. It is the post-quantum replacement for the classical signature schemes that authenticate almost everything today: RSA, ECDSA, and EdDSA. Where those rest on integer factorization and discrete logarithms — both broken in polynomial time by Shor's algorithm — ML-DSA rests on two lattice problems, Module-LWE and Module-SIS, for which no efficient quantum attack is known. It is NIST's primary, general-purpose PQC signature, alongside the hash-based SLH-DSA as a conservative backup.
Why it matters
Signatures do not share key exchange's harvest-now-decrypt-later urgency — a signature verified today cannot be forged retroactively — but they carry a longer tail. Firmware signing keys, code-signing roots, and long-lived certificates set trust anchors that must still resist a quantum adversary years into the future, so anything with a multi-year validity window needs a post-quantum path now. ML-DSA is the default for that transition: CNSA 2.0 selects ML-DSA-87 for national-security signatures, while ML-DSA-65 is the common general-purpose choice.
Sizes, parameters, and modes
FIPS 204 defines three parameter sets keyed to NIST security categories, and the operational surprise is size. An ML-DSA signature is one to two orders of magnitude larger than an ECDSA signature (~64–72 bytes), which changes protocol, certificate, and storage assumptions rather than being a drop-in swap:
- ML-DSA-44 — category 2 — public key 1312 B, signature ≈ 2420 B.
- ML-DSA-65 — category 3 — public key 1952 B, signature ≈ 3309 B; a common general-purpose default.
- ML-DSA-87 — category 5 — public key 2592 B, signature ≈ 4627 B; the CNSA 2.0 selection.
- Signing supports a deterministic mode and a randomized "hedged" mode; hedged is recommended for side-channel resistance.
Verification is the exposed operation
In deployment it is verification, not signing, that faces attacker-controlled input — and a conformant verifier must reject malformed public keys and signatures and handle domain separation and context strings correctly. Passing NIST's honest-input known-answer vectors does not prove any of that; the malformed and edge-case paths the vectors never exercise are exactly where nonconformant verifiers fail open. Treat conformance testing as a separate axis from a KAT run.
How quantakrypto helps
Choosing ML-DSA is straightforward; sizing the change and proving your implementation follows the standard is the load-bearing work. We inventory where RSA, ECDSA, and EdDSA signatures live across your firmware, PKI, and protocols (audit); plan and execute the move to ML-DSA — including the larger signatures' impact on certificates and bandwidth — without breaking production (migration); conformance-test the verifier you ship against FIPS 204's malformed-input and context-string behaviour (certification); and bring your engineers up to speed on lattice signatures and hedged signing (training).
Frequently asked questions
What is the difference between ML-DSA and Dilithium?
ML-DSA is the NIST-standardized version of the CRYSTALS-Dilithium submission, published as FIPS 204 on 13 August 2024. NIST fixed the parameters, encoding, and domain-separation rules in the final standard, so an implementation labelled "Dilithium" may target an earlier round that is not interoperable with FIPS 204 ML-DSA. Always confirm which one a library implements.
Which ML-DSA parameter set should I use?
ML-DSA-65 (security category 3) is the common general-purpose default and a reasonable starting point for most systems. CNSA 2.0 requires ML-DSA-87 (category 5) for U.S. national-security systems. ML-DSA-44 (category 2) offers the smallest keys and signatures where the threat model and size budget justify it.
How much larger are ML-DSA signatures than ECDSA?
Substantially. ECDSA signatures are roughly 64–72 bytes, while ML-DSA signatures range from about 2420 bytes (ML-DSA-44) to 4627 bytes (ML-DSA-87). Public keys grow similarly, from 1312 to 2592 bytes. This changes certificate sizes, handshake bandwidth, and storage assumptions, so it is not a transparent drop-in replacement.
Should I use deterministic or hedged signing?
FIPS 204 supports both a deterministic mode and a randomized "hedged" mode. Hedged signing mixes fresh randomness into each signature and is recommended for side-channel resistance, since it avoids repeating internal values that a physical attacker could exploit. Use deterministic mode only where a reliable randomness source is unavailable and the side-channel risk is understood.
Work with us on FIPS 204 (ML-DSA)
Related reading
References
- NIST: FIPS 204 — Module-Lattice-Based Digital Signature Standard (the normative parameter sets, sizes, and verification rules).
- NIST: Post-Quantum Cryptography project — standardization status, guidance, and related documents.
- Wikipedia: ML-DSA and Shor's algorithm for background on the scheme and the quantum threat it addresses.