NIST ML-DSA vs Dilithium: What Changed and Why It Matters

In August 2024, NIST published FIPS 204, standardizing what was previously known as CRYSTALS-Dilithium under the new name ML-DSA (Module Lattice-based Digital Signature Algorithm). This was not merely a rename. The standardization process introduced specific changes that affect implementations, interoperability, and migration planning. Understanding what changed and what remained the same is essential for any organization implementing post-quantum signatures.

The Origin: CRYSTALS-Dilithium

CRYSTALS-Dilithium was submitted to NIST's Post-Quantum Cryptography Standardization Project in 2017 by a team of academic researchers. It progressed through three rounds of evaluation, surviving increasingly rigorous security analysis and performance benchmarking. Dilithium was selected as the primary post-quantum signature algorithm in July 2022, alongside FALCON (as an alternative lattice scheme) and SPHINCS+ (as a hash-based alternative).

Dilithium's selection was based on several properties: strong security arguments based on the Module Learning With Errors (MLWE) problem, competitive performance, and implementation simplicity compared to alternatives like FALCON (which requires floating-point arithmetic for signature generation).

What Changed in Standardization

The Name

CRYSTALS-Dilithium became ML-DSA. NIST renamed all three primary algorithms to follow a consistent naming convention: ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA for signatures, and SLH-DSA (formerly SPHINCS+) for hash-based signatures. The "ML" prefix stands for "Module Lattice."

Parameter Set Names

Dilithium2/3/5 became ML-DSA-44/65/87. The numbers refer to internal parameters (k, l): ML-DSA-44 uses (k=4, l=4), ML-DSA-65 uses (k=6, l=5), ML-DSA-87 uses (k=8, l=7). The underlying parameters did not change.

Security Level Mapping

ML-DSA-44 targets NIST Level 2 (approximately 128-bit classical security). ML-DSA-65 targets Level 3 (approximately 192-bit). ML-DSA-87 targets Level 5 (approximately 256-bit). These mappings match the original Dilithium parameter sets.

Implementation Requirements

NIST tightened implementation requirements. Random number generation requirements were made more explicit, specifying approved DRBGs. Edge case handling in signature generation was clarified. Key and signature serialization was specified more precisely.

These changes mean that a FIPS 204 (ML-DSA) implementation is NOT byte-compatible with the original Dilithium specification. Keys and signatures from one cannot be verified by the other. Organizations that deployed pre-standardization Dilithium must plan migration to ML-DSA.

What Did Not Change

The core cryptographic construction is unchanged. The security proof, mathematical foundation (MLWE), signature generation, verification, and key generation algorithms are essentially the same. The security analysis that applied to Dilithium applies equally to ML-DSA. Performance characteristics are unchanged.

Key Sizes and Signature Sizes

ML-DSA-44 (Level 2): Public key: 1,312 bytes. Private key: 2,560 bytes. Signature: 2,420 bytes.

ML-DSA-65 (Level 3): Public key: 1,952 bytes. Private key: 4,032 bytes. Signature: 3,293 bytes.

ML-DSA-87 (Level 5): Public key: 2,592 bytes. Private key: 4,896 bytes. Signature: 4,595 bytes.

For comparison, RSA-2048 produces 256-byte signatures from 256-byte public keys. ECDSA P-256 produces 64-byte signatures from 32-byte public keys. ML-DSA signatures are an order of magnitude larger, but manageable for most enterprise use cases.

Performance Characteristics

ML-DSA-65 on modern hardware: key generation approximately 100 microseconds, signing approximately 150 microseconds, verification approximately 80 microseconds. Signing is faster than RSA-2048 (which takes about 1 millisecond). Verification is slightly slower than RSA-2048 (about 30 microseconds) but faster than ECDSA P-256 verification (about 150 microseconds).

H33's production implementation achieves sustained throughput exceeding 2.2 million authentications per second on Graviton4 hardware, with ML-DSA signature operations consuming approximately 35% of the per-authentication pipeline latency.

Practical Implications for Implementers

Use FIPS 204, Not the Competition Specification

If implementing ML-DSA today, target FIPS 204, not the CRYSTALS-Dilithium competition specification. The byte-level incompatibilities mean pre-standardization implementations will not interoperate with FIPS 204 implementations.

Choose ML-DSA-65 for Most Applications

ML-DSA-65 provides the best balance of security and performance. ML-DSA-44 is appropriate where signature size is critical and Level 2 security is acceptable. ML-DSA-87 is required by CNSA 2.0 for National Security Systems.

Combine with Other Signature Families

ML-DSA is based on the MLWE lattice problem. If a lattice cryptanalysis breakthrough occurs, ML-DSA could be weakened. H33 addresses this by combining ML-DSA with FALCON (NTRU lattice, a different assumption) and SLH-DSA (hash-based, independent of lattices). Breaks only if MLWE lattices, NTRU lattices, AND stateless hash functions are simultaneously broken -- three independent mathematical bets.

Plan for Certificate Infrastructure

ML-DSA certificates are larger than RSA or ECDSA certificates. A two-certificate chain with ML-DSA-65 adds approximately 10 KB to TLS handshakes compared to ECDSA. Certificate compression, session resumption, and caching mitigate the size increase.

The transition from CRYSTALS-Dilithium to ML-DSA is a standardization event, not a security event. The algorithm is the same. The security is the same. The performance is the same. What changed is specification precision, naming, and byte-level encoding. Implement FIPS 204 (ML-DSA), not the competition specification, and combine it with independent signature families for defense in depth.