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. It is also the parameter set DNSSEC adopted first: IANA assigned it DNSSEC algorithm number 18, and in September 2026 Cloudflare’s 1.1.1.1 resolver began validating it by default.
Sources: NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, Tables 1 and 2, August 2024; IANA, “Domain Name System Security (DNSSEC) Algorithm Numbers,” iana.org; S. Neuteboom and B. Westerbaan, “1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it,” Cloudflare, September 10, 2026, blog.cloudflare.com.
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. DNSSEC uses it as algorithm 18, and Cloudflare’s 1.1.1.1 validates it by default since September 2026.
- 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: FIPS 204 names each set “ML-DSA-𝑘ℓ,” where (𝑘, ℓ) are the dimensions of the matrix 𝐀, and for ML-DSA-44 that is (4, 4). It has nothing to do with 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 |
| DNSSEC algorithm number | 18 (mnemonic MLDSA44) |
The category-2 claim carries one condition in the standard itself. FIPS 204 §3.6.1 says the random bit generator used for ML-DSA-44 key generation “should have a security strength of at least 192 bits and shall have a security strength of at least 128 bits,” and that if an approved generator between 128 and 192 bits is used, “the claimed security strength of ML-DSA-44 is reduced from category 2 to category 1.”
For scale, an ML-DSA-44 signature is 2,420 bytes and its public key is 1,312 bytes, where a classical P-256 public-key coordinate pair is 32 bytes per coordinate and an ECDSA P-256 signature is 64 bytes. The bytes on the wire and in the certificate are what you plan around. Verification speed runs the other way: on the ESP32 measurement below, ML-DSA-44 certificate verification was about 12 times faster than ECDSA, and what bound it there was memory rather than compute.
Sources: NIST FIPS 204, Tables 1 and 2, August 2024, for the ML-DSA-44 sizes. NIST, “Digital Signature Standard (DSS),” FIPS 186-5 §6.4.1, February 2023, FIPS 186-5, for the ECDSA signature being the pair (r, s), each in [1, n−1], with the 256-bit P-256 order n in NIST SP 800-186 §3.2.1.3, csrc.nist.gov, putting each of r and s at 32 bytes.
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 help. The differences are modest and measurable: 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 heavy. When each signature adds bytes to a certificate, a log line, or a packet at scale, the smaller set reduces the cumulative footprint. DNSSEC is the clearest case, since even the 2,420-byte ML-DSA-44 signature overruns a 1,232-byte DNS UDP budget on its own.
- 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 about 12 times faster than ECDSA, adding about 16.5 ms against 194.2 ms, yet ML-DSA-44 was the dominant memory cost, adding 6 to 14 kB 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 rather than speed. See Constrained-Device PQC.
Sources: NIST FIPS 204, Tables 1 and 2, August 2024; Blanco-Romero et al., arXiv:2603.10274 (2026), Table 1 and the certificate-verification results.
Is ML-DSA-44 used in DNSSEC?
Yes. As of the registry’s August 10, 2026 update, it is the only post-quantum algorithm in IANA’s DNSSEC algorithm registry. IANA’s DNSSEC algorithm registry lists number 18 as ML-DSA-44, mnemonic MLDSA44, referencing the Internet-Draft “Module-Lattice Digital Signature Algorithm for DNSSEC,” which specifies ML-DSA keys and signatures in DNSSEC using “the ML-DSA-44 parameter set defined in FIPS 204.” That draft is still an Internet-Draft, with revision -04 dated August 11, 2026.
On September 10, 2026, Cloudflare announced that its 1.1.1.1 resolver “now validates DNSSEC signatures made with ML-DSA-44,” with validation on by default. The sizes are what make it hard: Cloudflare notes the 2,420-byte signature is “almost 38 times larger” than ECDSA P-256’s 64 bytes, so a signed answer exceeds common DNS-over-UDP limits and the authoritative server returns a truncated response that the resolver retries, usually over TCP. Because zones will publish ECDSA and ML-DSA-44 signatures side by side, 1.1.1.1 also requires a valid ML-DSA-44 path whenever the parent zone’s DS records list it, which blocks a downgrade to a forged classical signature.
The resolver is one step. Cloudflare lists ML-DSA-44 signing for its Authoritative DNS and DS support for its Registrar as its next step, and the chain of trust is post-quantum only once adoption reaches every parent zone up to the root. Cloudflare is describing its own products here, and one author of its post co-authors the draft. The full picture is in PQC in DNSSEC, and the threat it answers is the forge-later attack.
Sources: IANA DNSSEC algorithm registry, last updated 2026-08-10, iana.org; B. Westerbaan, S. Schmieg, draft-westerbaan-dnssec-mldsa-04, August 11, 2026, datatracker.ietf.org; Cloudflare, September 10, 2026, blog.cloudflare.com.
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.
What is ML-DSA-44’s DNSSEC algorithm number? 18, with the mnemonic MLDSA44, assigned by IANA and specified in the Internet-Draft draft-westerbaan-dnssec-mldsa. Cloudflare’s 1.1.1.1 resolver validates it by default since September 10, 2026.
Does anything reduce ML-DSA-44 below category 2? Key generation does, if its randomness is weak. FIPS 204 requires a random bit generator of at least 128 bits of security for ML-DSA-44 and recommends at least 192; with an approved generator between 128 and 192 bits, the claimed strength drops from category 2 to category 1.
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 the work I do.
Last verified 2026-09-15 · Updated 2026-09-15 · Maintained by Addie LaMarr, LaMarr Labs.