ML-DSA-44 is the smallest and fastest of the three ML-DSA parameter sets standardized by NIST in FIPS 204 in August 2024. It produces a 1312-byte public key, a 2420-byte signature, and a 2560-byte secret key. It sits at NIST Category 2, which is roughly between AES-128 and AES-192 against the best classical attacks. Verification takes well under a millisecond on modern hardware. ML-DSA-44 is the right choice when signature size and signing speed matter and the threat model does not require the highest possible margin. QNSQY uses ML-DSA-44 as the default signature algorithm in its Free tier.
This article walks through every parameter, every byte size, and explains exactly when ML-DSA-44 is the right pick and when it is not.
The Daily-Driver Pen Analogy
Imagine three pens in a stationery shop: a slim ballpoint, a sturdy gel pen, and a heavy fountain pen. The slim ballpoint is fast, light, and cheap. It writes everywhere, dries instantly, and slips into a shirt pocket. The gel pen has a larger reservoir and lays down a heavier line. The fountain pen makes the most beautiful signature but takes time to set up and goes through ink quickly.
ML-DSA-44 is the slim ballpoint. It signs fast, verifies fast, has compact keys, and works everywhere. ML-DSA-65 is the gel pen, the popular workhorse. ML-DSA-87 is the fountain pen for occasions where the heaviest possible signature is justified. All three are NIST FIPS 204 standardized, and all three resist quantum attackers.
Why a Lightweight Default Matters
Most signatures in the wild are not on treaty texts. They are on TLS handshakes, on software update manifests, on email DKIM records, on git commits. Each of those happens millions or billions of times per day. Speed and size matter. ML-DSA-44 trades a bit of security margin for snappier performance, which is the right call when the security floor is already well above current attack capability.
The Numbers in Detail
ML-DSA-44 parameters from FIPS 204, Section 4:
| Parameter | Value | Notes |
|---|---|---|
| n (polynomial degree) | 256 | Same across all three parameter sets |
| q (modulus) | 8380417 | Same across all three parameter sets (prime ~2^23) |
| (k, l) (matrix dimensions) | (4, 4) | Smaller than (6, 5) (65) or (8, 7) (87) |
| eta (secret key range) | 2 | Maximum value of secret coefficients |
| tau (number of plus/minus 1 in challenge) | 39 | Hashing parameter |
| beta (challenge bound) | 78 | tau * eta |
| omega (max number of "1" hints) | 80 | Hint vector limit |
| Public key | 1312 bytes | 32 + 32 k (bits in q) |
| Secret key | 2560 bytes | Includes A, t0, public key parts |
| Signature | 2420 bytes | Encoded vector z plus hint h plus challenge c |
| Decryption failure rate | ~0 | Protected by rejection sampling |
The (k, l) dimensions are the headline. ML-DSA-44 uses a 4-by-4 matrix module. Increasing k and l both increases security and increases signature size. ML-DSA-65 jumps to (6, 5), and ML-DSA-87 jumps to (8, 7).
Why "44"
The name "ML-DSA-44" refers to the (k, l) = (4, 4) parameter choice in the original Dilithium submission. NIST renamed CRYSTALS-Dilithium to ML-DSA but kept the parameter labels for traceability.
Security Level: NIST Category 2
NIST Category 2 means the scheme has at least the security of SHA-256 collision resistance. The estimated bit-strength against the best lattice attacks is roughly 2^128 quantum, which is a comfortable post-quantum floor.
| Category | Reference | Quantum strength |
|---|---|---|
| Category 1 | AES-128 key search | ~64 bits |
| Category 2 | SHA-256 collision search | ~128 bits |
| Category 3 | AES-192 key search | ~96 bits |
| Category 5 | AES-256 key search | ~128 bits |
Category 2 maps to "SHA-256 collision". This is a different reference than the AES-128 reference for Category 1, and it places ML-DSA-44 squarely between Category 1 and Category 3 in practical strength. For most signature use cases, Category 2 is sufficient.
When Category 2 Is Enough
For TLS server certificates with one-year rotation, software update signatures with monthly cycles, and email DKIM records, Category 2 is plenty. The signed material is short-lived (no signature is meaningful 50 years later), and the threat is forgery within the validity window. A quantum attacker who breaks the signature five years from now cannot retroactively forge yesterday's TLS certificate.
For long-lived signatures (treaty texts, intellectual property registrations, court documents), Category 3 or Category 5 is preferred. ML-DSA-65 or ML-DSA-87.
Speed Comparison
Numbers from Open Quantum Safe liboqs benchmarks on a Skylake-class x86 CPU at 3 GHz:
| Operation | ML-DSA-44 | ML-DSA-65 | ML-DSA-87 |
|---|---|---|---|
| Keygen | ~80 microseconds | ~140 microseconds | ~210 microseconds |
| Sign (avg) | ~280 microseconds | ~430 microseconds | ~640 microseconds |
| Verify | ~75 microseconds | ~120 microseconds | ~190 microseconds |
Sign times include rejection-sampling retries (the algorithm sometimes restarts because the candidate signature is too long). On a constrained device, the rejection-sampling tail can occasionally double signing time. Verification has no rejection step and is deterministic in time.
Why Sign Is Slower Than Verify
ML-DSA's signing uses Fiat-Shamir with abort, an interactive protocol made non-interactive by hashing. The "abort" step rejects signatures that leak too much information about the secret key, restarting with fresh randomness. Verification just runs once through the math and either accepts or rejects. The signing-side rejection loop is the source of variability.
When to Pick ML-DSA-44
Pick ML-DSA-44 when:
- You sign frequently and need throughput (DKIM, TLS handshakes, frequent commits).
- Signatures fit in space-constrained packets (TLS records, certificates).
- Threat model is short-lived: signed material is meaningful for under 10 years.
- You are building a free-tier consumer product (this is QNSQY Free's default).
- Compute budget is constrained (mobile, IoT, smart cards).
When NOT to Pick ML-DSA-44
Avoid ML-DSA-44 when:
- Signatures must remain unforgeable for 25+ years (treaty texts, archival).
- CNSA 2.0 alignment is required. CNSA 2.0 mandates ML-DSA-87 for top-tier national security.
- Regulatory framework requires Category 3 minimum (some healthcare archival, some financial long-term).
- You want maximum margin against unexpected lattice cryptanalysis.
How QNSQY Uses ML-DSA-44
QNSQY's Free tier uses ML-DSA-44 as the default signature algorithm, paired with Ed25519 in hybrid mode. The pairing ensures classical attackers cannot forge signatures even if lattice cryptanalysis advances unexpectedly, and quantum attackers cannot forge signatures even if Shor's algorithm breaks Ed25519.
| QNSQY Tier | Default ML-DSA | Other ML-DSA available | Other DSA available |
|---|---|---|---|
| Free | ML-DSA-44 hybrid | None | None |
| Pro | ML-DSA-65 hybrid | 44, 87 | None |
| Business | ML-DSA-65 hybrid | 44, 87, plus pure-PQC modes | SLH-DSA, FN-DSA, LMS |
For hybrid mode, ML-DSA-44 + Ed25519 produces a signature roughly 2420 + 64 = 2484 bytes, plus a fixed-size hybrid header. This is small enough for most envelope formats.
Why Pair with Ed25519
Ed25519 has a 32-byte public key and a 64-byte signature. Combined with ML-DSA-44, the total public key is 1344 bytes (1312 + 32) and the total signature is 2484 bytes (2420 + 64). The Ed25519 piece adds minimal overhead (less than 5%) but provides full classical security against today's attackers. If lattice math falls, classical Ed25519 still holds against today's adversaries. If Shor's algorithm breaks Ed25519 in the future, ML-DSA-44 still holds against quantum adversaries.
How ML-DSA-44 Computes a Signature Step by Step
The signing process follows the Fiat-Shamir with abort framework. Step one: the signer hashes the message together with the public key into a per-signing seed using SHAKE-256. Step two: the signer samples a random masking vector y from a uniform distribution. Step three: the signer computes w1 = HighBits(Ay), where A is the public matrix. Step four: the signer hashes w1, the message, and the public key with SHAKE-256 to produce a challenge c with exactly tau=39 nonzero +/-1 coefficients. Step five: the signer computes z = y + c*s1, where s1 is part of the secret key.
If z has any coefficient outside [-(gamma1 - beta), gamma1 - beta], the signer rejects this candidate and restarts step two with new randomness. If z passes, the signer also computes a hint vector h that lets verification reconstruct w1 from a compressed form. The final signature is (c, z, h). Verification recomputes Az - c*t (where t is in the public key), uses h to recover w1, and checks that the SHAKE-256 hash of w1, message, public key matches c.
The "with abort" rejection step is what makes the security argument work. By rejecting candidates that lie close to the boundary, the algorithm prevents the signer from leaking information about s1 through correlations with the publicly visible z. The expected number of rejections per signature is around 4 to 7, so the average sign cost includes that retry overhead.
Why Sign-Time Variability Matters in Some Settings
For a desktop application signing one file, variability in sign time is invisible. For a TLS handshake at peak load on a busy server, the 99th-percentile sign time can be 2x to 3x the average due to rejection-sampling worst cases. In rare cases, a single signing call has been observed to take 10x the average before successful completion. Production deployments typically use a hard timeout to prevent pathological corner cases from blocking other operations.
This is one of the design considerations that led to the FN-DSA (Falcon) family. FN-DSA has deterministic sign time but uses floating-point Gaussian sampling, which is harder to make constant-time. ML-DSA's variable-time signing with simple integer arithmetic was the trade-off NIST chose to standardize first, with FN-DSA standardization coming later in FIPS 206.
Side-Channel Considerations
ML-DSA-44 has known timing-attack surfaces in naive implementations, particularly in the Number Theoretic Transform and the rejection sampling. The FIPS 204 specification includes constant-time guidance, and reference implementations (the official "dilithium" repo, plus liboqs and pqcrypto-mldsa) follow it.
QNSQY uses the audited pqcrypto-mldsa implementation, constant-time on supported CPUs.
| Side channel | Mitigation |
|---|---|
| Timing | Constant-time NTT, branchless rejection sampling |
| Power analysis | Application-level (out of scope for software lib) |
| Cache | Constant-time table lookups |
| Fault injection | Independent verification step within sign function |
Frequently Asked Questions
What does the "44" mean in ML-DSA-44?
It refers to the Dilithium parameter labels (k=4, l=4). NIST adopted the historical naming when standardizing the algorithm.
Is ML-DSA-44 enough for a software update signature?
For most software updates with monthly to yearly cadences, yes. The signed material is the update manifest, valid for the rotation period. Long-archival cases (firmware in critical infrastructure that lives 30 years) may prefer ML-DSA-65 or ML-DSA-87.
How does ML-DSA-44 compare to RSA-2048 in size?
RSA-2048 has a 256-byte signature and a 256-byte public key. ML-DSA-44 has a 2420-byte signature and a 1312-byte public key. ML-DSA is roughly 10x larger but quantum-resistant.
Can I use ML-DSA-44 for code signing?
Yes. Microsoft, Apple, and other code-signing services are evaluating ML-DSA. For long-lived archives (decades), the conservative choice is ML-DSA-65 or higher.
How does ML-DSA-44 compare to FN-DSA-512 (Falcon-512)?
FN-DSA-512 has smaller signatures (about 666 bytes) but more complex signing math (NTRU lattices, requires careful implementation). ML-DSA-44 has larger signatures but simpler implementation (Module-LWE, easier to make constant-time). For high-volume signing where bandwidth dominates, FN-DSA-512 wins; for general-purpose signing where simplicity matters, ML-DSA-44 wins.
Sources
- NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (August 2024). https://csrc.nist.gov/pubs/fips/204/final
- Bai, S. et al. "CRYSTALS-Dilithium Algorithm Specifications." NIST PQC Round 3 (2021). https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf
- NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process (2022). https://csrc.nist.gov/pubs/ir/8413/upd1/final
- NSA CNSA 2.0 Cybersecurity Advisory (September 2022). https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
- NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024). https://csrc.nist.gov/pubs/fips/203/final
Related Articles
- ML-DSA vs SLH-DSA
- Lattice-Based Cryptography Explained
- Hybrid Encryption Explained
- What Is Post-Quantum Cryptography
- NIST FIPS Guide
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.