ML-DSA Explained: How CRYSTALS-Dilithium Became FIPS 204

If your organization deployed CRYSTALS-Dilithium during the NIST competition years and you are treating ML-DSA as a drop-in successor, you likely have a key rotation problem that library patching alone may not resolve. NIST published FIPS 204 on August 13, 2024, making ML-DSA an active federal standard — and Appendix D of that specification documents encoding and algorithmic changes relative to the Dilithium round-3 submission that typical implementations do not treat as wire-compatible. For security architects currently designing post-quantum signature infrastructure, the distinction between Dilithium and ML-DSA is not academic. It is a deployment constraint.

From Competition Finalist to Federal Standard: The Dilithium-to-ML-DSA Transition

CRYSTALS-Dilithium was selected as a NIST PQC finalist and served as the reference design throughout the competition evaluation period. The standardization process, however, did not simply ratify Dilithium as-is. NIST used the transition from competition candidate to federal standard to introduce specification-level changes — changes comprehensive enough that FIPS 204 dedicates Appendix D specifically to documenting the differences from the Dilithium round-3 submission. The practical result is that ML-DSA and CRYSTALS-Dilithium are not generally wire-compatible: a signature produced by a Dilithium implementation will typically not be verifiable by an ML-DSA implementation using the same nominal parameters, and vice versa, unless the implementation explicitly supports both variants.

This matters operationally because a significant number of early-mover organizations, open-source libraries, and hardware security module vendors began integrating Dilithium between 2019 and 2023 — prior to FIPS 204 finalization. Any system in that cohort that has not explicitly confirmed ML-DSA (FIPS 204) conformance should be treated as a key rotation candidate rather than an upgrade-in-place candidate. This is an architectural recommendation, not a regulatory mandate, but it reflects the scope of the differences documented in Appendix D. The audit action is concrete: pull your inventory of Dilithium integrations, cross-reference against Appendix D of FIPS 204, and flag anything that predates August 13, 2024 without a confirmed conformance statement. Security architects evaluating the broader PQC standards landscape — including how ML-KEM diverges from its CRYSTALS-Kyber competition roots — will find similar specification-level changes across the NIST finalization process.

How ML-DSA Actually Works: The Module-Lattice Foundation

ML-DSA is built on the hardness of the Module Learning With Errors (MLWE) problem and the Module Short Integer Solution (MSIS) problem — both variants of lattice problems that are believed to resist attacks from both classical and quantum adversaries. The signing mechanism follows a Fiat-Shamir with aborts paradigm: a signer generates a commitment, receives a challenge derived from a hash of the message and commitment, and produces a response that is accepted only if it satisfies specific norm bounds — with rejection sampling used to prevent the response from leaking information about the private key.

The practical consequence of this construction is that signing performance depends on the rejection sampling rate, which varies by parameter set. Verification, by contrast, is computationally inexpensive relative to signing. For architects designing high-throughput systems — certificate issuance pipelines, code signing infrastructure, or authentication services — this asymmetry between signing and verification cost is a relevant capacity planning input. Both FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) are module-lattice-based schemes derived from the CRYSTALS family, and a deeper treatment of lattice-based cryptography performance and migration architecture provides useful context for architects modeling system-level throughput.

Parameter Sets Decoded: Choosing Between ML-DSA-44, -65, and -87

FIPS 204 defines three parameter sets, each targeting a different NIST security category. The key and signature sizes — which directly affect certificate chain size, storage requirements, and protocol overhead — are specified in Table 1 of FIPS 204 as follows:

• ML-DSA-44 — AES-128 equivalent security. Public key: 1,312 bytes. Private key: 2,560 bytes. Signature: 2,420 bytes.
• ML-DSA-65 — AES-192 equivalent security. Public key: 1,952 bytes. Private key: 4,032 bytes. Signature: 3,309 bytes.
• ML-DSA-87 — AES-256 equivalent security. Public key: 2,592 bytes. Private key: 4,896 bytes. Signature: 4,627 bytes.

To calibrate the infrastructure impact: an RSA-2048 signature is 256 bytes, making ML-DSA-44 signatures roughly 9.5× larger at 2,420 bytes. The public key inflation is even more pronounced relative to elliptic curve schemes — an ECDSA P-256 public key is 64 bytes uncompressed, compared to ML-DSA-44's 1,312 bytes, a 20× increase. Certificate chains carrying multiple ML-DSA public keys will be substantially larger than their classical equivalents, with direct implications for TLS handshake sizes and constrained-bandwidth environments.

Parameter set selection should be driven by threat model and system constraints, not simply by defaulting to the highest security level. For general enterprise applications with data sensitivity at or below the AES-128 equivalent threshold, ML-DSA-44 is the appropriate choice. ML-DSA-65 (AES-192 equivalent) covers the midrange. ML-DSA-87 is warranted for long-lived credentials or high-value assets where AES-256-equivalent security is required. ML-DSA-87's Category 5 security strength aligns with CNSA 2.0's highest security level requirements for National Security Systems, though CNSA 2.0 does not explicitly mandate ML-DSA-87 by parameter set name — the alignment is based on matching security strength requirements.

Variants, Modes, and the Side-Channel Warning You Cannot Ignore

FIPS 204 specifies multiple signing variants: a deterministic mode, a hedged (randomized) mode, and HashML-DSA — a variant designed for use when the message is processed through an approved hash function prior to signing. Each variant exists to address different implementation contexts, but the specification does not treat them as equivalent in terms of security risk.

FIPS 204 notes that randomized (hedged) signing is preferred in environments exposed to side-channel or fault-injection risks, as the introduction of per-signature randomness mitigates scenarios in which a computation fault during signing could expose private key material. Additional analysis in draft-connolly-cfrg-ml-dsa-security-considerations, a CFRG security-considerations draft, provides more explicit characterization of concrete fault-recovery attacks against deterministic mode. Architects specifying ML-DSA for hardware security modules, smart cards, or any environment where physical fault injection is a plausible threat vector should specify the hedged variant in their implementation requirements and verify that the target implementation supports it.

HashML-DSA is relevant for interoperability with legacy protocol flows that expect pre-hashed message inputs, but architects should verify that the hash function used is an approved algorithm and that the HashML-DSA variant is explicitly supported by the implementation in question — it is a distinct algorithm specification, not simply deterministic mode with a hash prepended.

Infrastructure Reality Check: Key Sizes, Certificate Chains, and CNSA 2.0 Fit

The size increases documented above translate directly into infrastructure planning requirements. PKI deployments that issue certificates at scale will need to account for larger certificate payloads across their full chain — root, intermediate, and end-entity certificates all carry ML-DSA public keys and signatures. A three-level chain using ML-DSA-44 would carry public keys and signatures totaling several kilobytes before any subject metadata is included, compared to under 1 KB for a comparable RSA-2048 chain.

For National Security Systems subject to CNSA 2.0, the parameter set question has a clearer answer: CNSA 2.0 mandates adoption of post-quantum algorithms on specific timelines, and ML-DSA-87's AES-256-equivalent security strength aligns with the highest security level requirements for NSS. Architects working in that environment should consult the CNSA 2.0 compliance deadline matrix by system type to confirm which timelines apply to their specific system categories — the deadlines vary by system type and are not uniform.

Storage systems, certificate databases, and any infrastructure that caches or logs certificates will also need capacity adjustments. The difference between RSA-2048 and ML-DSA-87 public key storage is roughly an order of magnitude, and at enterprise scale with millions of certificates, the cumulative impact warrants inclusion in capacity planning budgets.

Protocol Integration Landscape: Where ML-DSA Fits Today

One of the more advanced protocol integration efforts underway is the IETF LAMPS working group's work on ML-DSA use within the Cryptographic Message Syntax (CMS). As of early 2025, this was progressing as draft-ietf-lamps-cms-ml-dsa-02; that work has since been published as RFC 9882, Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS). CMS is the signature format underlying S/MIME, code signing, and a range of PKI-dependent protocols, and the finalization of RFC 9882 is a meaningful step forward for production deployments in those contexts.

Architects should treat protocol-layer readiness as a checklist item distinct from algorithm readiness. FIPS 204 is finalized — the parameter sets, key formats, and signing procedures are normative. Protocol integration of those primitives into specific wire formats has been advancing, with CMS now covered by a final RFC, though TLS integration, certificate profile updates, and OCSP/CRL format considerations remain active areas where standards work continues. Planning for production deployment of ML-DSA in protocol-dependent systems requires verifying the current RFC status of each relevant protocol integration, as this landscape is still evolving.

Key Takeaways

• ML-DSA (FIPS 204) was published as a finalized federal standard on August 13, 2024 — it is not a draft or a recommendation, and U.S. agencies and contractors are expected to adopt it.
• ML-DSA is not generally wire-compatible with CRYSTALS-Dilithium. FIPS 204 Appendix D documents encoding and algorithmic differences from the round-3 submission; typical implementations do not cross-verify signatures between the two schemes. Any pre-FIPS-204 Dilithium implementation should be treated as a key rotation candidate rather than an upgrade-in-place candidate.
• Three parameter sets are defined — ML-DSA-44, -65, and -87 — targeting AES-128, AES-192, and AES-256 equivalent security levels respectively. Signature sizes range from 2,420 to 4,627 bytes, roughly 9–18× larger than RSA-2048.
• FIPS 204 notes that randomized (hedged) signing is preferred over deterministic mode in environments exposed to side-channel or fault-injection threats. CFRG security-considerations analysis provides further detail on concrete fault-recovery attacks against deterministic mode. The hedged variant should be the default choice for implementations in physical or fault-injection-exposed environments.
• CMS protocol integration for ML-DSA has been published as RFC 9882. Architects should verify the current RFC status of any other protocol-layer integrations relevant to their deployments, as the broader standardization landscape continues to develop.
• Immediate action: audit all Dilithium implementations in your environment against FIPS 204 Appendix D before assuming compatibility. This is recommended architecture practice, not a regulatory requirement.

Related Reading

On this site:

• How CRYSTALS-Kyber was transformed into the finalized ML-KEM standard
• NIST's finalized PQC standards - ML-KEM, ML-DSA, and HQC for security architects
• CNSA 2.0 compliance deadlines broken down by system type

Primary sources:

• FIPS 204 official specification - Module-Lattice-Based Digital Signature Standard
• NIST CSRC FIPS 204 landing page and normative publication record
• IETF LAMPS working group draft on ML-DSA integration into CMS

This article draws on primary documentation from NIST FIPS 204 (August 2024), the NIST CSRC PQC project page, and IETF LAMPS draft-ietf-lamps-cms-ml-dsa-02. All claims verified against official sources as of April 2026.