In M3 you saw that ML-KEM (key encapsulation) rests on Module-LWE. ML-DSA is a signature algorithm that uses the same mathematical foundation (Module-LWE, the “noisy linear equations” of M2) but does a different job: signing a message and verifying that signature. FIPS 204’s own definition sums up why a signature matters: it detects “unauthorized modifications” and authenticates the signer’s identity; ML-DSA is “believed to be strongly unforgeable”. In FIPS 204’s own words, one consequence is non-repudiation: “a signature generated by this scheme can be used as evidence in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory… the signatory cannot easily repudiate the signature at a later time.” This concept (a signatory cannot later deny their own signature) is one of the basic assumptions of e-signature infrastructures; it is the property ML-DSA preserves, not changes, through the PQC transition (note for ADVISOR: it is the same legal concept eIDAS and CAdES infrastructures already rely on).
FIPS 204: status and origin
ML-DSA is defined in FIPS 204, which has FINAL2024-08-13 status. In FIPS 204’s own words: “ML-DSA is derived from one of the selected schemes, CRYSTALS-Dilithium.” So just as ML-KEM derives from CRYSTALS-Kyber, ML-DSA is the standardized form of the NIST competition finalist CRYSTALS-Dilithium. The algorithm itself has been a public design studied worldwide since 2017 (Dilithium’s first published specification); the name changed, but the math is not new (2016 is when NIST launched its call, see M2).
Three parameter sets: sizes and categories
FIPS 204 defines three parameter sets, named after their matrix dimensions (ML-DSA-k``l): ML-DSA-44 (public key 1312 BSOURCED, signature 2420 BSOURCED, category 2SOURCED), ML-DSA-65 (pk 1952 BSOURCED, signature 3309 BSOURCED, category 3SOURCED), ML-DSA-87 (pk 2592 BSOURCED, signature 4627 BSOURCED, category 5SOURCED).
There is a trap to watch for here: in M3 you saw that ML-KEM-512 is category 1, and got used to the pattern “512 is a small number, low category”. But on the ML-DSA side the pattern does not work the same way: the smallest ML-DSA set (44) is not category 1 but category 2. FIPS 204’s own Table 1 lists this explicitly, and it proves that the numeric naming of the two families does not sit on the same category scale. Saying in a meeting “we use ML-KEM-512 and ML-DSA-44 together, both are the lowest level”, without checking, is an assumption made without looking at the category table; ML-DSA-44 is actually one category stronger than ML-KEM-512.
Why there are three options
In M3 you saw that ML-KEM-768 is NIST’s default recommendation; similar logic applies on the ML-DSA side. ML-DSA-65 (category 3) is a balanced choice for most general-purpose uses: according to NIST SP 800-57’s own comparable-strength table, category 3 corresponds to AES-192/RSA-7680 on the classical side (FIPS 204 itself does not give this equivalence; it comes from SP 800-57). ML-DSA-87 (category 5) is for scenarios where you want the highest assurance (long-lived root certificates, government-level secrecy requirements); ML-DSA-44 (category 2) is for narrow scenarios where bandwidth or storage is truly critical and it can be justified that the lower category 2 is really enough. The choice should rest on “which category is defensible for this job”, not “use the smallest” (note for ADVISOR: in the M9 lesson key-ceremony-and-kmip you will see the concrete effect of this choice in a root CA key ceremony).
Numbers to know
ML-DSA-44: pk 1312 B, sig 2420 B, category 2. ML-DSA-65: pk 1952 B, sig 3309 B, category 3. ML-DSA-87: pk 2592 B, sig 4627 B, category 5
Trap: ML-KEM-512 is category 1, but ML-DSA-44 (the smallest ML-DSA set) is category 2; the numeric suffixes of the two families are not on the same category scale
Lab: Verify FIPS 204's own parameter table
[not run] This is a reading and verification exercise, not a runnable command
# Open nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf and find Table 1 on page 15
Recorded output
In the "Claimed security strength" row you will see Category 2 for ML-DSA-44, Category 3 for ML-DSA-65 and Category 5 for ML-DSA-87
At the table
How to say this in a bank meeting.
To an executive
ML-DSA signatures carry non-repudiation just like RSA and ECDSA signatures. That means our e-signature and CAdES infrastructure keeps its basic legal-validity assumption through the PQC transition; only the signature size changes.
To an architect
ML-DSA-65 is the default choice in most scenarios (the same NIST recommendation logic you saw for ML-KEM-768 in M3). Choose ML-DSA-44 only in a scenario with extremely constrained bandwidth or storage, and only if you can justify that category 2 (not category 1) is really sufficient.
Objection
“"ML-DSA-44 is the smallest and fastest option. Let's use it by default, like ML-KEM-512."”
Answer
They are not in the same category: ML-KEM-512 is category 1 but ML-DSA-44 is category 2, so ML-DSA-44 actually carries a stronger security claim than ML-KEM-512. This is a concrete example that the assumption 'smallest number, lowest security' does not work the same way in the two families; you need to check each family's own category table.
NIST, 2020. The primary source for the table of equivalence between NIST categories and classical algorithms (AES-192 ~ RSA-7680); FIPS 204 itself does not give this equivalence
Table 2 (comparable strengths) / 5 min
Checkpoint
Answer first, then compare with the model answer and score yourself against the rubric. Saved in this browser only.
01Recall
What are the exact public key and signature sizes of ML-DSA-65, and which NIST category is it?
Model answer
ML-DSA-65 has a 1952-byte public key, a 3309-byte signature, and is NIST category 3.
02Recall
Which NIST competition finalist was FIPS 204 derived from, and what status does it have today?
Model answer
In FIPS 204's own words, ML-DSA is derived from one of the selected schemes, CRYSTALS-Dilithium. It has been FINAL since 13 August 2024.
03Scenario
An architect proposes choosing ML-DSA-44 for consistency because they use ML-KEM-512, assuming both are 'category 1, the lowest level'. How do you correct this assumption?
Model answer
The assumption is wrong: ML-KEM-512 is category 1, but ML-DSA-44 (the smallest ML-DSA set) is category 2; the numeric suffixes of the two families do not sit on the same category scale. So ML-DSA-44 actually carries a security claim one category stronger than ML-KEM-512; saying 'both are the lowest level' for consistency is an assumption made without checking the category table.
A complete answer includes
Your score: 0/3
04Hostile
An auditor asks 'Is an ML-DSA signature as legally binding as an RSA signature?' How do you answer based on FIPS 204's own wording?
Model answer
According to FIPS 204's own wording, a signature produced by ML-DSA carries non-repudiation: it can be used to prove to a third party that the signature was really produced by the claimed signatory, and the signatory cannot easily repudiate it later. That is the same legal concept RSA and ECDSA signatures carry and that e-signature infrastructures rely on; it is a property ML-DSA preserves, not changes, through the PQC transition.
A complete answer includes
Your score: 0/3
Project linkThe rationale for choosing the ML-DSA variant for the certificate and signature chain in Project 2 (PQC PKI); a prerequisite for the size comparison in the M9 lesson `key-ceremony-and-kmip`.