Is ML-DSA the Same as CRYSTALS-Dilithium? FIPS 204 Explained

The Short Answer

ML-DSA and CRYSTALS-Dilithium are the same algorithm. ML-DSA is the name the National Institute of Standards and Technology (NIST) assigned to Dilithium when it was standardised as FIPS 204 in August 2024. The underlying mathematics, parameter sets, and security properties are identical. The naming change is purely administrative: NIST uses the prefix ML (Module Lattice) for all lattice-based standards, and DSA (Digital Signature Algorithm) for its signature schemes.

If you encounter ML-DSA in a compliance document, a government procurement specification, or a FIPS-certified product description, it refers to exactly the same algorithm that cryptography researchers have published, implemented, and analysed under the name CRYSTALS-Dilithium since 2017. Understanding what changed in the transition from competition submission to NIST standard, and what stayed the same, matters for developers who need to implement, certify, or audit systems using this algorithm.

What Is CRYSTALS-Dilithium?

CRYSTALS-Dilithium is a digital signature scheme based on the Module Learning With Errors (MLWE) problem. It was developed by a team of cryptographers from ETH Zurich, the French National Institute for Research in Computer Science (INRIA), and Ruhr University Bochum, and submitted to NIST's Post-Quantum Cryptography Standardisation competition in 2017. CRYSTALS stands for Cryptographic Suite for Algebraic Lattices; the suite includes both Dilithium (signatures) and Kyber (key encapsulation).

Dilithium went through three rounds of public analysis, attack attempts, and parameter refinement before NIST selected it as its primary post-quantum signature standard in 2022, with formal publication of the standard following in August 2024. For a detailed treatment of how the algorithm works and the mathematics behind it, see the full CRYSTALS-Dilithium explainer.

How NIST's Naming Convention Works

NIST standardised four post-quantum algorithms in 2024. Each received a new name that follows a consistent pattern: algorithm family prefix, hyphen, descriptor. The mapping is:

• CRYSTALS-Dilithium became ML-DSA (Module Lattice Digital Signature Algorithm), standardised as FIPS 204
• CRYSTALS-Kyber became ML-KEM (Module Lattice Key Encapsulation Mechanism), standardised as FIPS 203
• SPHINCS+ became SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardised as FIPS 205
• FALCON became FN-DSA (Fast-Fourier Transform Lattice-Based Digital Signature Algorithm)

The "ML" prefix in ML-DSA and ML-KEM indicates that both are based on module lattice problems. The distinction between a Digital Signature Algorithm (DSA) and a Key Encapsulation Mechanism (KEM) reflects the different cryptographic functions: ML-DSA signs and verifies, ML-KEM establishes shared secrets. For the full context of the NIST standards, see NIST post-quantum cryptography standards 2024.

Security Level Mapping: ML-DSA-44, ML-DSA-65, ML-DSA-87

Dilithium was submitted and analysed at three security levels, corresponding to NIST's security categories. In the standardised form, each level has a new designation. The mapping is direct and the parameters are identical:

The numbers in the ML-DSA names (44, 65, 87) refer to internal module dimensions and polynomial parameters in the algorithm specification, not to security bit levels. ML-DSA-44 does not mean 44-bit security: it corresponds to roughly 128-bit classical security, which translates to approximately 128-bit post-quantum security against the best known lattice attacks.

What Changed Between Dilithium and ML-DSA?

NIST made a small number of parameter changes between the final Dilithium round-3 submission and the published FIPS 204 standard. The core mathematical construction, the security argument, and the parameter sizes are identical. The changes that were made are:

• Deterministic signing is now the default: The round-3 submission supported both randomised and deterministic signing modes. FIPS 204 makes deterministic signing the specified mode, which simplifies implementation and eliminates one class of implementation errors related to weak random number generators during signing.
• Context string parameter added: FIPS 204 added an optional context string parameter to the signing and verification APIs. This allows applications to domain-separate signatures by context, preventing a signature intended for one use from being valid in a different context. The parameter defaults to an empty string and is backwards-compatible with the round-3 specification.
• Prehash mode formalised: FIPS 204 formalises a HashML-DSA mode for signing large messages by hashing them before signing. This was an informal practice with Dilithium and is now a defined part of the standard.

None of these changes alter the security properties of the algorithm. Implementations of round-3 Dilithium that did not use the randomised signing mode are compatible with ML-DSA at the byte level for the core signing operations.

Why the Naming Distinction Matters for FIPS Certification

For organisations operating under compliance frameworks that reference FIPS-approved algorithms, the naming distinction matters because FIPS 204 is the approved standard and CRYSTALS-Dilithium (the competition submission) is not. A FIPS-certified cryptographic module must implement ML-DSA as specified in FIPS 204, not the round-3 submission, even though the mathematical core is the same.

In practice, most well-maintained implementations of Dilithium have tracked the NIST process and updated to the FIPS 204 specification. The open-source reference implementation maintained by the algorithm authors is aligned with FIPS 204. Libraries including liboqs (Open Quantum Safe), Bouncy Castle, and the pqcrypto Rust crate have published FIPS 204-compliant versions. When evaluating a library for production use, verify that it references FIPS 204 compliance rather than the round-3 submission.

For high-volatility environments where interoperability between implementations is critical, the context string parameter in FIPS 204 provides a mechanism to ensure signatures from one implementation cannot be used in a different application context. This is particularly relevant for blockchain networks where multiple node implementations must verify signatures produced by any compliant signer. A context string set to the chain identifier, for example, prevents replay attacks across different networks using the same key material. The post-quantum cryptography guide covers the broader standardisation landscape and how each algorithm fits into a production security architecture.

Which Security Level Should You Use?

The choice between ML-DSA-44, ML-DSA-65, and ML-DSA-87 is a trade-off between security margin and performance. All three levels are considered secure against the best known quantum attacks. The differences are in how much headroom they provide above the minimum security threshold.

ML-DSA-44 (Dilithium2) provides approximately 128-bit quantum security. This is the minimum security level recommended by NIST for new deployments. It is appropriate for applications where signature size and verification speed are primary concerns and a 128-bit security margin is considered sufficient for the expected threat environment.

ML-DSA-65 (Dilithium3) targets approximately 192-bit security. The size increase relative to ML-DSA-44 is moderate, and the additional security margin may be worth the overhead for applications that sign long-lived data where the cost of a cryptographic failure would be severe.

ML-DSA-87 (Dilithium5) targets approximately 256-bit security, equivalent to AES-256. This is the level that QuanChain deploys across all 20 TADEQS security tiers. The choice of the highest security level reflects the architecture's goal of providing security margins that remain comfortable even if lattice cryptanalysis improves significantly over the operational lifetime of the network. For more on how QuanChain structures post-quantum security, see the TADEQS system explained.

For a detailed look at how the signature sizes at each level affect blockchain throughput, see why Dilithium's 2420-byte signatures are a blockchain throughput problem.

Implementation Checklist for ML-DSA

For developers integrating ML-DSA into a new system, the practical steps are:

• Use a library that explicitly states FIPS 204 compliance, not round-3 Dilithium compliance, if FIPS certification matters for your deployment
• Confirm that the library implements deterministic signing by default, as specified in FIPS 204
• Define a context string for your application domain and pass it to the signing and verification functions to prevent cross-application signature reuse
• If signing messages larger than the algorithm's direct input can handle efficiently, use the HashML-DSA mode specified in Section 5.4 of FIPS 204
• Account for public key sizes (1,312 to 2,592 bytes) as well as signature sizes when planning storage and bandwidth requirements. Public keys stored in a UTXO set or account state will accumulate rapidly on a chain with many active addresses

The size implications for blockchain storage are covered in detail in the signature size and throughput analysis. The broader context of how NIST selected and structured all four post-quantum standards is in NIST post-quantum cryptography standards 2024.

ML-DSA is not a different algorithm from CRYSTALS-Dilithium. It is Dilithium after NIST applied its editorial and minor technical refinements, gave it a standardised name, and published it as a FIPS document. The security properties, parameter sizes, and implementation complexity are unchanged.

For organisations evaluating post-quantum readiness, the distinction between "implements Dilithium" and "implements ML-DSA per FIPS 204" is real but narrow: it is primarily about the context string addition, deterministic signing by default, and FIPS certification eligibility. The underlying algorithm is the same lattice construction that the cryptographic community has spent seven years analysing and attacking without finding a practical break.