up:: FIPS 204 (ML-DSA)
ML-DSA-44
ML-DSA-44 is the smallest of the three parameter sets defined in FIPS 204, the primary NIST post-quantum standard for digital signatures, and it targets NIST security category 2. It does the same signing job as its larger siblings, proving that a certificate, a software update, or a signed record came from the expected signer and was not altered, and it produces the smallest artifacts of the family, a 1,312-byte public key and a 2,420-byte signature. Those are still far larger than the tens of bytes a classical ECDSA signature carries, which is the pattern for every post-quantum signature. ML-DSA-44 is the lightweight end of the general-purpose default; teams that want a category-3 margin start at ML-DSA-65 instead.
Source: NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, Tables 1 and 2, August 2024.
The short version:
- ML-DSA-44 does digital signatures, proving authenticity and integrity. It is not for key establishment. (Key exchange is ML-KEM.)
- It sits at NIST security category 2, the lowest of the three ML-DSA tiers.
- Its public key is 1,312 bytes, its private key is 2,560 bytes, and its signature is 2,420 bytes.
- It is the smallest ML-DSA set, useful where signature and key size press hardest, while ML-DSA-65 is the common category-3 starting default.
- Its security rests on lattice math (Module-LWE and Module-SIS), which Shor’s algorithm does not break.
What is ML-DSA-44?
ML-DSA-44 is the category-2 parameter set of ML-DSA, the standardized form of the algorithm known during the NIST competition as CRYSTALS-Dilithium. A signature scheme works in three moves: the signer generates a public verification key and a private signing key, signs a message or its digest with the private key, and anyone holding the public key checks that the signature is valid for that exact message. ML-DSA-44 runs that protocol with the smallest parameters in the family, which is why its keys and signatures are the smallest of the three sets.
The “44” refers to the dimensions of the internal lattice matrix the parameter set uses, not to a key length in bits. What it tracks in practice is the security category: ML-DSA-44 is claimed at category 2, below ML-DSA-65 at category 3 and ML-DSA-87 at category 5. The security of all three rests on the Module-LWE and Module-SIS problems over a polynomial ring, lattice hardness assumptions with no known efficient solution on a classical or a quantum computer, which is what makes ML-DSA the replacement for the ECDSA and RSA signatures that Shor’s algorithm forges.
Source: NIST FIPS 204, §4, August 2024.
What are ML-DSA-44’s sizes and security category?
The parameters are the thing to internalize, because they are where the engineering cost lives. These figures are verbatim from Table 2 (sizes in bytes) and Table 1 (security categories) of the standard.
| Property | Value |
|---|---|
| NIST security category | Category 2 |
| Private key | 2,560 bytes |
| Public key | 1,312 bytes |
| Signature | 2,420 bytes |
For scale, an ML-DSA-44 signature is 2,420 bytes and its public key is over a kilobyte, where a classical elliptic-curve public key is 32 bytes and an ECDSA signature is a small fraction of ML-DSA’s. Signing and verifying are fast enough for mainstream use, so the bytes on the wire and in the certificate are what you plan around, not the compute.
Source: NIST FIPS 204, Tables 1 and 2, August 2024.
When would you use ML-DSA-44 instead of ML-DSA-65?
ML-DSA-65 is the typical starting default for category-3 deployments, so ML-DSA-44 is the choice when a lower tier is acceptable and the smaller artifacts genuinely help. The differences are modest but real: ML-DSA-44’s public key is 1,312 bytes against ML-DSA-65’s 1,952, and its signature is 2,420 bytes against 3,309. Where signatures accumulate in certificate chains, signed tokens, or bandwidth-limited transport, that difference can matter. The cases where ML-DSA-44 earns the pick:
- Category 2 is accepted by policy. The lower security margin should be a documented decision, since everything the signature vouches for inherits that margin.
- Size pressure is real. When each signature adds bytes to a certificate, a log line, or a packet at scale, the smaller set reduces the cumulative footprint.
- The verifier ecosystem is fixed. In closed systems where every verifier is under your control, the tier choice is a straightforward policy call rather than an interoperability negotiation.
On constrained hardware the tradeoff can shift in ML-DSA-44’s favor on speed. In a 2026 measurement on an ESP32 running DTLS 1.3, certificate verification with ML-DSA-44 was roughly 11 times faster than ECDSA, about 17 ms against 194 ms, yet ML-DSA-44 was the dominant memory cost, adding several kilobytes of code and about 28 kB of peak heap over the ECDSA build. On small devices ML-DSA is fast but memory-hungry, and the binding constraint is heap footprint, not speed. See Constrained-Device PQC.
Sources: NIST FIPS 204, Tables 1 and 2, August 2024; Blanco-Romero et al., arXiv:2603.10274 (2026), Tables 1 and 5.
Common misconceptions
- “The 44 means a 44-bit or 44-byte key.” It does not. The number reflects the dimensions of the internal lattice matrix and maps to security category 2, not to a key or signature length. The signature is 2,420 bytes.
- “ML-DSA-44 is too weak to trust.” It is a NIST-standardized category-2 set. Not being the common category-3 starting default is a different statement from insecure. The right question is whether category 2 suits the role.
- “Smaller parameters mean weaker math.” All three ML-DSA sets rest on the same Module-LWE and Module-SIS problems. The smaller set targets a lower category with smaller artifacts, not a different foundation.
- “ML-DSA-44 is a drop-in for ECDSA.” Same role, very different dimensions. Its kilobyte-plus public key and 2,420-byte signature ripple into certificates, parsers, and trust stores, so it is a planned migration, not a swap.
Questions people ask
Is ML-DSA-44 secure? Yes, as a NIST-standardized category-2 signature set. Its security rests on the same lattice problems as the larger sets, and Shor’s algorithm does not break it. Whether category 2 is enough is a policy question about the role.
Why would I choose ML-DSA-44 over ML-DSA-65? For smaller artifacts when category 2 is acceptable. Its public key and signature are meaningfully smaller than ML-DSA-65’s, which helps where signatures accumulate or transport is tight.
How much smaller is ML-DSA-44 than ML-DSA-65? Its public key is 1,312 bytes against 1,952, its signature is 2,420 bytes against 3,309, and its private key is 2,560 bytes against 4,032.
Does ML-DSA-44 do key exchange? No. It is a signature algorithm, so it proves authenticity and integrity only. Key establishment is the job of ML-KEM.
Is ML-DSA-44 the general-purpose default? ML-DSA-65 is the common category-3 starting default for general-purpose signing. ML-DSA-44 is the lighter category-2 option for roles where its smaller size pays and the lower tier is accepted.
Everything here is the map, given freely. When your team needs the right ML-DSA parameter set chosen against your own certificate and verifier constraints, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.