ML-DSA-65 is the middle parameter set of the ML-DSA family in NIST FIPS 204. It produces a 1952-byte public key, a 3293-byte signature, and a 4032-byte secret key. It sits at NIST Category 3 (AES-192-equivalent quantum security). For most TLS, code-signing, and document-signing deployments, this is the parameter set the engineering community converged on. CNSA 2.0 specifies ML-DSA-65 as the floor for general-purpose post-quantum signatures, and Cloudflare, Apple, and Microsoft have signaled this as the default in their PQC migration plans.
This article walks through every parameter, explains why ML-DSA-65 is the balanced default, and shows how QNSQY Pro and Business deploy it.
The Daily Workhorse Pen Analogy
If ML-DSA-44 is the slim ballpoint and ML-DSA-87 is the heavy fountain pen, ML-DSA-65 is the gel pen that most office workers carry. It writes well, lasts long enough, and works on everything from forms to whiteboards. There is no single use case where it is the perfect optimum, but for a wide range of tasks it is the best general-purpose choice.
The TLS and code-signing communities reached the same conclusion: ML-DSA-65 hits the sweet spot of security, signature size, and verification speed for the majority of internet-scale signing applications.
Why Engineers Like the Middle Parameter
ML-DSA-44 is fast and small but only Category 2. ML-DSA-87 is the safest but signatures balloon to nearly 5 kilobytes. ML-DSA-65 gives Category 3 (the regulatory bar that most jurisdictions consider acceptable for sensitive data) at a 3-kilobyte signature, which fits in normal TLS records and most envelope formats.
The Numbers in Detail
ML-DSA-65 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) | (6, 5) | Larger than 44, smaller than 87 |
| eta (secret key range) | 4 | Larger than 44's eta=2 |
| tau (challenge weight) | 49 | Larger than 44's tau=39 |
| beta (challenge bound) | 196 | tau * eta |
| omega (max number of "1" hints) | 55 | Hint vector limit |
| Public key | 1952 bytes | Larger than 44's 1312 |
| Secret key | 4032 bytes | Larger than 44's 2560 |
| Signature | 3293 bytes | Larger than 44's 2420 |
The key trade-off is that eta jumps from 2 to 4. This widens the secret-key coefficient range and makes the underlying lattice problem harder, at the cost of slightly larger signatures.
Why eta Jumps from 2 to 4
In ML-DSA-44, the secret key has small coefficients in the range [-2, 2]. In ML-DSA-65, the range expands to [-4, 4]. The wider range gives more entropy per coefficient, which translates to harder lattice instances. The signature size increases proportionally because the algorithm must encode a value somewhere in this wider space.
Security Level: NIST Category 3
NIST Category 3 means the scheme has at least the security of AES-192 against quantum attackers. The estimated bit-strength is roughly 2^192 classical and 2^160 quantum. CNSA 2.0 from the NSA, dated September 2022, specifies ML-DSA-65 as the floor for non-top-secret signatures.
| Use case | Recommended ML-DSA | Reason |
|---|---|---|
| TLS server signatures (long-lived) | ML-DSA-65 | Category 3 fits TLS bandwidth |
| Code signing | ML-DSA-65 | Long-lived archives, rotation possible |
| Healthcare archival | ML-DSA-65 | 50+ year retention with margin |
| Financial transactions | ML-DSA-65 | SOX/Basel III alignment |
| National security top secret | ML-DSA-87 | CNSA 2.0 max-tier requirement |
| Treaty texts | ML-DSA-87 | Maximum margin |
QNSQY Pro and Business default to ML-DSA-65 in hybrid mode for these reasons.
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 |
ML-DSA-65 is roughly 60% slower than ML-DSA-44 for sign and verify. For high-volume DKIM or TLS handshake signing, that 60% can matter. For document signing, certificate issuance, and most application-level signing, the difference is invisible to users.
The Rejection-Sampling Tail
ML-DSA's signing process can occasionally take much longer than average due to rejection sampling. The signing function generates a candidate signature, checks it against length and form constraints, and retries with fresh randomness if it fails the check. The 99th-percentile sign latency is roughly 2x the average, and the 99.9th-percentile is roughly 3x.
For QNSQY's file encryption use case, this variability is invisible because signing happens once per file and on the order of milliseconds. For TLS handshake signing at thousands per second, the tail matters and is worth measuring.
CNSA 2.0 Alignment
The NSA's CNSA 2.0 advisory specifies the floor for post-quantum signatures in national-security systems. ML-DSA-65 is acceptable for general-purpose use, with ML-DSA-87 required for top-tier classified material.
| CNSA 2.0 algorithm | Required parameter | Standard |
|---|---|---|
| KEM | ML-KEM-1024 | NIST FIPS 203 |
| Signature (general) | ML-DSA-65 | NIST FIPS 204 |
| Signature (top-secret) | ML-DSA-87 | NIST FIPS 204 |
| Symmetric | AES-256-GCM | FIPS 197 |
| Hash | SHA-384 or SHA-512 | FIPS 180-4 |
For commercial entities working with US Department of Defense or with classified information, ML-DSA-65 is the default and ML-DSA-87 is required for the highest tier.
Hybrid with Ed25519
QNSQY pairs ML-DSA-65 with Ed25519 in hybrid mode. The combined signature is roughly 3293 + 64 = 3357 bytes, plus a fixed-size hybrid header.
| Component | Public key size | Signature size |
|---|---|---|
| Ed25519 | 32 bytes | 64 bytes |
| ML-DSA-65 | 1952 bytes | 3293 bytes |
| Hybrid combined | 1984 bytes | 3357 bytes |
Hybrid mode means both signatures must verify for the file to be considered authentic. If either fails, verification rejects. This protects against unexpected breaks in either algorithm.
Why Concatenation Works
Hybrid signatures are a simple concatenation: the verifier checks the Ed25519 signature, then checks the ML-DSA-65 signature, and accepts only if both pass. There is no clever reduction; the security argument is purely from intersection. As long as one algorithm holds, forgery is impossible.
How QNSQY Uses ML-DSA-65
QNSQY Pro defaults to ML-DSA-65 in hybrid mode. Business defaults to the same but unlocks ML-DSA-87, SLH-DSA variants, FN-DSA-512/1024, and LMS for users who want signature diversity.
| QNSQY tier | Default signature | Other available |
|---|---|---|
| Free | ML-DSA-44 hybrid | None |
| Pro | ML-DSA-65 hybrid | ML-DSA-44, ML-DSA-87 |
| Business | ML-DSA-65 hybrid | All ML-DSA, SLH-DSA, FN-DSA, LMS, plus pure-PQC modes |
The default tier choice is what most customers actually deploy. ML-DSA-65 in Pro and Business is the production default.
Why Different Algorithms in Business Tier
Business unlocks SLH-DSA, FN-DSA, and LMS not because ML-DSA is insufficient but because diversity matters. If lattice cryptanalysis advances unexpectedly and breaks ML-KEM and ML-DSA together, having SLH-DSA (hash-based) signatures still gives a working backup. SLH-DSA's security depends only on hash functions, which have an entirely different cryptanalysis history.
| Signature family | Hardness assumption | Backup value |
|---|---|---|
| ML-DSA-65 | Module-LWE, Module-SIS (lattice) | Primary, fast |
| SLH-DSA | Hash function security | Conservative backup, slow signing |
| FN-DSA-512 (Falcon) | NTRU lattice | Smaller signatures, complex math |
| LMS | Hash function security, stateful | Embedded systems, requires state mgmt |
Pure-PQC modes (no Ed25519 backup) are also available in Business for users who explicitly want a 100% post-quantum posture.
Migrating From ECDSA to ML-DSA-65 in Practice
Most organizations today sign with ECDSA on the P-256 curve. ECDSA-P256 has 64-byte signatures and 64-byte public keys (including the curve point compression). ML-DSA-65 has 3293-byte and 1952-byte equivalents, roughly 50x larger combined. Migration steps look like:
| Step | Action | Tooling |
|---|---|---|
| 1 | Inventory ECDSA usage (TLS certs, code-signing, document signatures) | OpenSSL, certutil scripts |
| 2 | Test ML-DSA-65 with pilot users in hybrid mode | OpenSSL 3.5+, BoringSSL with PQC |
| 3 | Update CA infrastructure to issue hybrid certificates | EJBCA, internal PKI |
| 4 | Roll new certificates to non-production traffic | Standard cert deployment |
| 5 | Monitor handshake success rates and packet fragmentation | TLS metrics, packet captures |
| 6 | Roll to production traffic by service tier | Service-by-service rollout |
The largest practical pain point during migration is fragmentation. ECDSA signatures and certificates fit easily in single TLS records; ML-DSA-65 hybrid certificates push past 4KB with the chain, which can fragment at the IP layer on misconfigured networks. Cloudflare's deployment notes specifically called out this issue and recommended path-MTU-discovery configuration changes for some legacy networks.
Implementation Quality Markers
When evaluating an ML-DSA-65 implementation, the markers of high quality include constant-time arithmetic across the entire NTT and inverse NTT, branchless rejection sampling, secure RNG seeding (getrandom on Linux, BCryptGenRandom on Windows), and clean failure modes when randomness is unavailable. The reference Dilithium implementation, the liboqs library from Open Quantum Safe, and the pqcrypto-mldsa Rust crate all meet these criteria.
QNSQY's implementation chain is: pqcrypto-mldsa wraps the official PQClean Dilithium reference, which itself is hardened against timing attacks and has been audited by multiple academic teams during the NIST PQC standardization process. The Rust binding adds memory-safety guarantees against use-after-free and double-free errors that have historically affected C-based crypto libraries.
Real-World Deployment Status as of 2026
The post-quantum signature deployment landscape in 2026 is a mix of pilot programs and production rollouts.
| Organization | Status | Algorithm |
|---|---|---|
| Cloudflare TLS edge | Production hybrid signatures pilot | ML-DSA-65 + Ed25519 |
| Apple iMessage PQ3 | Production (2024+) | Apple-internal, Category 5 |
| Microsoft SymCrypt | Production support, opt-in | ML-DSA-65, ML-DSA-87 |
| OpenSSL 3.5 | Production support | All ML-DSA, all SLH-DSA |
| AWS KMS | Production support, opt-in | ML-DSA, ML-KEM |
| Google Workspace | Pilot | TBD, likely ML-DSA-65 |
| Linux distros (Fedora, Debian) | Available in standard libraries | Via OpenSSL 3.5+ |
For organizations starting their post-quantum migration in 2026, ML-DSA-65 hybrid is the recommended default. It has the broadest tooling support, the clearest regulatory alignment, and the best-documented performance characteristics of any post-quantum signature available today.
Frequently Asked Questions
Why is ML-DSA-65 the recommended default?
It hits NIST Category 3 (AES-192-equivalent quantum security) which aligns with CNSA 2.0's general-purpose floor. Signature size (3293 bytes) fits in TLS records. Sign and verify times are well under a millisecond on modern CPUs. The trade-off between security and performance is in the right place for most use cases.
How does ML-DSA-65 compare to RSA-3072?
RSA-3072 has 384-byte signatures and 384-byte public keys. ML-DSA-65 has 3293-byte signatures and 1952-byte public keys. ML-DSA-65 is roughly 8x larger but quantum-resistant.
Is ML-DSA-65 fast enough for high-volume TLS?
Yes. Sign times around 430 microseconds and verify times around 120 microseconds support thousands of TLS handshakes per second per core, which matches typical web server requirements.
Why does CNSA 2.0 specify both ML-DSA-65 and ML-DSA-87?
CNSA 2.0 mandates Category 5 (AES-256-equivalent) for top-tier national security, which is ML-DSA-87. For non-top-secret national security work, Category 3 is sufficient, which is ML-DSA-65. The two-tier structure matches the existing classification hierarchy.
Can I migrate from ML-DSA-65 to ML-DSA-87 later?
Yes. QNSQY Business supports both. Existing files signed with ML-DSA-65 can be re-signed at ML-DSA-87 (or the original signatures can be retained alongside new ones). There is no algorithmic obstacle.
Sources
- NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (August 2024). https://csrc.nist.gov/pubs/fips/204/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
- 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
- Cloudflare Research, Post-quantum cryptography blog series (2024). https://blog.cloudflare.com/post-quantum-key-agreement/
- NIST FIPS 205, Stateless Hash-Based Digital Signature Standard (August 2024). https://csrc.nist.gov/pubs/fips/205/final
Related Articles
- ML-DSA vs SLH-DSA
- FN-DSA Falcon Explained
- Hybrid Encryption Explained
- Lattice-Based Cryptography Explained
- 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.