# CRYSTALS-Dilithium: From Submission to ML-DSA Standard **Source**: https://quantumsequrity.com/blog/crystals-dilithium-history **Category**: PQC Algorithms --- [← Back to Blog](../../blog.html) PQC Algorithms # CRYSTALS-Dilithium: From Submission to ML-DSA Standard 12 min read CRYSTALS-Dilithium occupies a parallel place in post-quantum signature standardization to what Kyber occupies in key encapsulation. Submitted to NIST in 2017 alongside Kyber, selected for standardization in 2022, and finalized as FIPS 204 in August 2024 under the new official name ML-DSA. The two algorithms grew up together as part of the CRYSTALS suite, sharing a common mathematical heritage in module lattices and a common research team. This post walks through Dilithium's history. The original submission, the cryptographic technique called Fiat-Shamir with aborts that powers signing, the iterative refinements through NIST's three rounds, and the renaming from Dilithium to ML-DSA. ## The CRYSTALS-Dilithium Submission CRYSTALS-Dilithium was submitted to NIST in November 2017 as part of the original Round 1 PQC submission cohort. The submission documented an elegant lattice-based signature scheme designed for performance and implementation simplicity. The Dilithium team brought together expertise spanning lattice-based cryptography, secure implementation, and signature scheme design. The named authors of the original submission included Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, Peter Schwabe, Gregor Seiler, and Damien Stehlé. Many of these names also appear on the Kyber submission, reflecting the shared CRYSTALS team structure. The Dilithium submission targeted three security categories that would later be standardized: Category 2, Category 3, and Category 5. The corresponding parameter sets were Dilithium2 (now ML-DSA-44), Dilithium3 (now ML-DSA-65), and Dilithium5 (now ML-DSA-87). ## The Module-LWE Foundation Dilithium's security rests on a combination of Module-LWE and Module-SIS (Short Integer Solution) hardness assumptions. These are the same general lattice problem family that underlies Kyber, but Dilithium uses both Module-LWE and Module-SIS in different parts of its construction. Module-LWE protects the secret key from extraction. Module-SIS prevents signature forgeries. The combination provides EUF-CMA (Existential Unforgeability under Chosen Message Attack) security under standard lattice assumptions. The advantage of using both Module-LWE and Module-SIS is that breaking the scheme requires solving either problem, which provides a stronger security argument than relying on a single assumption. The disadvantage is that the resulting parameter sets must be sized for both assumptions, which adds some bytes compared to schemes using only one. ## Fiat-Shamir with Aborts Dilithium uses a signing technique called Fiat-Shamir with aborts. This is a variant of the classical Fiat-Shamir transform combined with rejection sampling. The technique was developed specifically for lattice-based signatures, where the original Fiat-Shamir transform produces signatures that leak information about the secret key. The basic idea is as follows. The signer commits to randomness, derives a challenge from the message and commitment via a hash function, and responds to the challenge using their secret key. If the response is too "large" (in lattice geometry terms), it would leak information about the secret key. The signer detects this by checking the response's size and aborts if necessary, retrying with new randomness. The "aborts" part is the rejection sampling step. The signer keeps trying until the response is small enough to be safely revealed. The expected number of attempts is small (typically 4-7 for typical Dilithium parameter sets). The cost of these aborts shows up in signing time, but verification is unaffected. Fiat-Shamir with aborts is mathematically elegant. The aborts serve a critical security role by preventing secret key leakage. The technique was first introduced by Lyubashevsky in 2009 and refined by subsequent work, eventually forming the basis of Dilithium's design. ## NIST PQC Round 1 (2017-2019) NIST announced its PQC standardization process in February 2016 with submission deadline of November 2017. NIST received 69 algorithm submissions, of which 64 entered Round 1 after initial screening. Many of these were lattice-based signature schemes. Round 1 lattice-based signature submissions included Dilithium, FALCON, qTESLA, BLISS, and several others. The diversity of lattice-based signature designs reflected the active research field at the time. Some submissions used Fiat-Shamir with aborts. Others used different approaches like trapdoor sampling or hash-based commitments. In January 2019, NIST announced 26 schemes advancing to Round 2. Dilithium was among them. Several lattice-based competitors did not advance. ## NIST PQC Round 2 (2019-2020) Round 2 ran for about a year and a half. The cryptographic community examined each Round 2 candidate for security flaws, performance characteristics, and implementation considerations. During Round 2, the Dilithium team made several refinements. The team published Dilithium-AES, an alternative version that used AES-CTR for some hash operations to potentially improve performance on platforms with AES acceleration. They tweaked parameter choices to maintain a comfortable security margin against the best known attacks. In July 2020, NIST announced Round 3 finalists and alternates. Dilithium was selected as a Round 3 finalist for digital signatures. The other finalists were FALCON and Rainbow. SPHINCS+ was selected as an alternate. Several Round 2 schemes were eliminated. ## NIST PQC Round 3 (2020-2022) and Selection Round 3 was the deciding round for signatures. NIST gave the finalists roughly two years for further analysis. Important developments during Round 3 affected the field. The Rainbow signature scheme was broken in a 2022 attack by Beullens. This eliminated Rainbow from contention and left Dilithium and FALCON as the lattice-based finalists. Dilithium received continued security analysis with no significant weaknesses identified. The Fiat-Shamir with aborts construction was studied in detail and confirmed sound. Performance benchmarking demonstrated that Dilithium was among the fastest signature schemes on diverse platforms. In July 2022, NIST announced selection. CRYSTALS-Dilithium was selected as the primary digital signature standard for general use cases. FALCON was selected for applications requiring smaller signatures. SPHINCS+ was selected as the hash-based alternative. This three-pronged selection acknowledged that no single signature scheme is optimal for all use cases. Dilithium handles general signing well. FALCON wins when signature size is critical. SPHINCS+ provides hash-based foundation diversity for high-assurance applications. ## From Dilithium to ML-DSA Between the July 2022 selection and the August 2024 final standard publication, NIST went through its formal standardization process. NIST renamed CRYSTALS-Dilithium to ML-DSA. ML stands for Module-Lattice. The renaming aligned Dilithium's name with NIST's broader naming convention for the post-quantum suite. ML-KEM, ML-DSA, SLH-DSA, and FN-DSA all share consistent naming based on their underlying mathematical foundations. The renaming was administrative. The algorithm itself was essentially unchanged from the final Dilithium Round 3 specification. Implementation libraries that supported Dilithium needed only minor updates to align with FIPS 204 specifics. In August 2024, NIST published FIPS 204 as the final standard. ML-DSA was now an official NIST cryptographic standard. For more on the FIPS standards, see [NIST FIPS Guide](../nist-fips-guide.html). ## Parameter Sets in FIPS 204 FIPS 204 standardizes three parameter sets for ML-DSA. ML-DSA-44 targets NIST Category 2, slightly stronger than AES-128. Public key 1,312 bytes, signature 2,420 bytes. ML-DSA-65 targets Category 3, equivalent to AES-192. Public key 1,952 bytes, signature 3,309 bytes. ML-DSA-87 targets Category 5, equivalent to AES-256. Public key 2,592 bytes, signature 4,627 bytes. These parameter sets correspond to Dilithium2, Dilithium3, and Dilithium5 from the original submission, with minor encoding adjustments. The mathematical structure and security analysis carried over directly. The fact that ML-DSA-44 targets Category 2 rather than Category 1 is a quirk of NIST's category mapping. Category 2 sits between Category 1 and Category 3 in strength. ML-DSA does not have a Category 1 parameter set. ## Real-World Deployment ML-DSA is now deployed in production systems worldwide. Code-signing services, certificate authorities, and digital signature applications integrate ML-DSA. Browser vendors are rolling out support for ML-DSA in TLS certificate signing. Email signing, document signing, and software publisher signing are all migrating toward ML-DSA. For most deployments, ML-DSA-65 is the default choice. It targets Category 3, which is the typical regulatory minimum for sensitive signing. Public key and signature sizes are modest. Performance is fast on modern hardware. ML-DSA-87 is reserved for high-assurance deployments that specifically require Category 5 security. The size and performance overhead is small enough that most users could pay it, but Category 3 is sufficient for most threat models. ML-DSA-44 is used for bandwidth-constrained applications where Category 2 security is acceptable. It is the smallest ML-DSA parameter set and the appropriate choice when signature size matters but Category 2 is enough. For more on signature scheme choices, see [ML-DSA vs SLH-DSA](../mldsa-vs-slhdsa.html). ## QNSQY's ML-DSA Implementation QNSQY exposes ML-DSA at all three parameter sets. Free tier users get ML-DSA-44. Pro tier users get ML-DSA-65 and ML-DSA-87. Business tier users get the full suite of post-quantum signatures including ML-DSA, FN-DSA, and SLH-DSA. QNSQY uses the reference ML-DSA implementation, which has been validated against NIST's published Known Answer Tests for FIPS 204. The implementation is constant-time and resistant to standard side-channel attacks. The QNSQY CLI accepts ML-DSA-44, ML-DSA-65, or ML-DSA-87 as DSA algorithm choices on signing operations. The choice of parameter set determines the security category and the resulting signature size. ## Comparing Dilithium with FALCON in Standardization The selection of both Dilithium (now ML-DSA) and FALCON (now FN-DSA) reflects NIST's recognition that no single lattice-based signature scheme optimizes for all use cases. ML-DSA wins on implementation simplicity. Integer-only operations, deterministic across hardware, and easier to audit for side-channel resistance. FN-DSA wins on signature size. Roughly half the signature size of ML-DSA at the same security category. The trade-off is floating-point requirements during signing. For most general-purpose signing, ML-DSA is the right default. For applications where signature size is critical, FN-DSA is the right choice. NIST's standardization of both gives implementers flexibility. For more on FN-DSA, see [FN-DSA Falcon Explained](../fn-dsa-falcon-explained.html). ## Industry Reaction to FIPS 204 Publication The August 2024 publication of FIPS 204 marked the formal arrival of ML-DSA as a standardized signature scheme. Years of preparation by vendors and standard bodies came to fruition. Code-signing services began rolling out ML-DSA support. Major operating system vendors announced ML-DSA support for software signature verification. Certificate authorities began issuing ML-DSA-signed certificates for testing and early-adopter use cases. The IETF working groups updated their drafts to reference FIPS 204. CMS (Cryptographic Message Syntax), X.509 certificates, and other signature-bearing standards updated to support ML-DSA signatures. Cryptographic library maintainers updated their packages. liboqs, OpenSSL providers, and many others added FIPS 204-aligned ML-DSA implementations. Cross-implementation testing using NIST KAT vectors became routine. For developers, the practical impact is that ML-DSA is now a stable target for production deployment. The algorithm is unlikely to change. Implementations are mature. Toolchains support it. ## Implementation Maturity ML-DSA reference implementations are mature. The original Dilithium reference implementation has received extensive scrutiny over the seven-year standardization process. Multiple independent implementations have been developed and cross-validated against the reference. For QNSQY users, this maturity translates into confidence that ML-DSA implementations are correct and secure. The reference implementations have been integrated into major cryptographic libraries including OpenSSL (via providers), libsodium-extensions, and various language-specific cryptographic packages. For more on what FIPS validation means in practice, see [NIST FIPS Guide](../nist-fips-guide.html). ## FAQ ### Why was Dilithium renamed to ML-DSA? NIST renamed all selected algorithms to align with a consistent naming convention based on mathematical foundations. ML-KEM, ML-DSA, SLH-DSA, and FN-DSA share this convention. ### Are Dilithium and ML-DSA cryptographically identical? The algorithms are essentially the same with minor encoding adjustments specified in FIPS 204. Implementations that supported Dilithium Round 3 needed minor updates to align with the FIPS 204 final specification. ### Which lattice problem does ML-DSA rely on? ML-DSA relies on both Module-LWE and Module-SIS. The combination provides a stronger security argument than relying on a single problem. ### Is ML-DSA EUF-CMA secure? Yes. ML-DSA provides EUF-CMA security (Existential Unforgeability under Chosen Message Attack), the standard security notion for digital signatures. The Fiat-Shamir with aborts construction ensures this security under the random oracle model. ### How does ML-DSA differ from RSA in deployment? ML-DSA produces larger signatures than RSA-2048 (2,420 bytes vs 256 bytes for ML-DSA-44 vs RSA-2048). ML-DSA has post-quantum security; RSA does not. ML-DSA signing and verification are both faster than RSA on modern hardware. ## Sources 1. [NIST FIPS 204: Module-Lattice-Based Digital Signature Standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) 2. [NIST PQC Project: ML-DSA Selection Documentation](https://csrc.nist.gov/projects/post-quantum-cryptography) 3. [CRYSTALS-Dilithium Round 3 Specification](https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf) 4. [IACR Cryptology ePrint: CRYSTALS-Dilithium Algorithm Design](https://eprint.iacr.org/2017/633) 5. [NIST PQC Standardization Process Reports](https://csrc.nist.gov/publications/detail/nistir/8413/final) ## Related Articles - [CRYSTALS-Kyber History](../crystals-kyber-history.html) - [ML-DSA vs SLH-DSA](../mldsa-vs-slhdsa.html) - [Lattice-Based Cryptography Explained](../lattice-based-cryptography-explained.html) - [NIST FIPS Guide](../nist-fips-guide.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)