FIPS 204 (ML-DSA): the post-quantum digital signature

The terms on this page

ML-DSAModule-Lattice-based Digital Signature Algorithm: the standardised post-quantum replacement for RSA and ECDSA signatures, published as FIPS 204
FIPSFederal Information Processing Standard: the US government's standards series, and where the post-quantum algorithms were published

Also mentioned

RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry (new tab), ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry (new tab), SLH-DSASLH-DSAStateless Hash-based Digital Signature AlgorithmStateless Hash-Based Digital Signature Algorithm, the NIST-standardized signature scheme derived from SPHINCS+ and specified in FIPS 205.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab), PKIPKIpublic key infrastructurePublic Key Infrastructure, the framework of certificate authorities, certificates, and policies that binds public keys to identities and enables trust in TLS, code signing, and email.Read the full entry (new tab), CNSACNSACommercial National Security Algorithm SuiteThe Commercial National Security Algorithm Suite 2.0, the NSA's mandated algorithm set for US National Security Systems.Read the full entry (new tab), KATKATknown answer testA test that feeds an implementation a fixed input with a published correct output and checks that it produces exactly that.Read the full entry (new tab) are defined in the glossary.

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, because 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.

Pitfall

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.

Implementation status

Go 1.27 moved ML-DSA into its standard library on 19 August 2026. The new crypto/mldsa package implements all three FIPS 204 parameter sets, crypto/x509 reads and writes ML-DSA keys and signatures, and crypto/tls can use ML-DSA-44, ML-DSA-65, and ML-DSA-87 in TLS 1.3. The release changes what Go teams can test now, but library support is not automatic deployment. Applications still need compatible certificate chains, peers, operational controls, and a supported Go Cryptographic Module where a FIPS boundary applies.

DNSSEC integration

Cloudflare announced ML-DSA-44 validation on 1.1.1.1 on 10 September 2026. The DNSSEC deployment adds a protocol use beyond certificates. The DNSSEC draft specifies pure ML-DSA with an empty context string, a 1,312 byte public key and a 2,420 byte signature. Its algorithm number is 18 in the IANA registry; the protocol document remains an Internet-Draft.

Test transport and acceptance policy separately. RFC 9715 recommends a maximum 1,400 byte DNS UDP payload, with smaller limits allowed, so the signature alone already exceeds that budget. RFC 6840 permits a validator to accept one valid path: publishing conventional and post-quantum signatures together therefore does not by itself require the stronger path. Quantum resistance needs authenticated downgrade protection through the delegations to the trust anchor, as well as a verifier that supports the primitive.

Sizing the signature change, and proving it conforms

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)

Conformance certificationProve an ML-KEM / ML-DSA / SLH-DSA implementation actually follows the standard.Get certified Migration engineeringPlan and execute the move to post-quantum algorithms without breaking production.Plan a migration

References

NIST: FIPS 204: Module-Lattice-Based Digital Signature Standard (the normative parameter sets, sizes, and verification rules).
NIST: Post-Quantum Cryptography project, covering standardization status, guidance, and related documents.
Go: Go 1.27 release notes, documenting ML-DSA support in crypto/mldsa, crypto/x509, and crypto/tls.
Go: crypto/mldsa package documentation, including parameter sets, sizes, and Go Cryptographic Module availability.
Cloudflare: ML-DSA-44 DNSSEC validation, announced 10 September 2026.
IETF: ML-DSA for DNSSEC, revision 04, work in progress.
IETF: RFC 9715 on response sizes and RFC 6840 section 5.11 on validator acceptance.
Wikipedia: ML-DSA and Shor's algorithm for background on the scheme and the quantum threat it addresses.

FIPS 204 (ML-DSA)