up:: FIPS 204 (ML-DSA)
ML-DSA-65
ML-DSA-65 is the middle of the three parameter sets defined in FIPS 204, the primary NIST post-quantum standard for digital signatures, and it is the common starting default for general-purpose signing. It targets NIST security category 3 and does the signing job of proving that a certificate, a software update, or a signed record came from the expected signer and was not altered, with a 1,952-byte public key and a 3,309-byte signature. Those artifacts are large next to a classical ECDSA signature but generally more manageable than the conservative hash-based signatures of SLH-DSA, which is a large part of why ML-DSA-65 is where most category-3 signature migrations begin.
Source: NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, Tables 1 and 2, August 2024.
The short version:
- ML-DSA-65 does digital signatures, proving authenticity and integrity. It is not for key establishment. (Key exchange is ML-KEM.)
- It sits at NIST security category 3, the middle of the three ML-DSA tiers.
- Its public key is 1,952 bytes, its private key is 4,032 bytes, and its signature is 3,309 bytes.
- It is the typical general-purpose starting default, the signature counterpart to ML-KEM-768 on the key-exchange side.
- Its security rests on lattice math (Module-LWE and Module-SIS), which Shor’s algorithm does not break.
What is ML-DSA-65?
ML-DSA-65 is the category-3 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-65 runs that protocol at the balanced middle parameters, stronger than ML-DSA-44 and lighter than ML-DSA-87.
The “65” 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-65 is claimed at category 3, between ML-DSA-44 at category 2 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-65’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 3 |
| Private key | 4,032 bytes |
| Public key | 1,952 bytes |
| Signature | 3,309 bytes |
For scale, an ML-DSA-65 signature is 3,309 bytes and its public key is nearly two kilobytes, where a classical elliptic-curve public key is 32 bytes. Signing and verifying are fast enough for mainstream adoption, which is one reason NIST built ML-DSA as the general-purpose default, so the bytes in the certificate and on the wire are the planning constraint, not the compute.
Source: NIST FIPS 204, Tables 1 and 2, August 2024.
Why is ML-DSA-65 the common starting default?
ML-DSA-65 lands where most general-purpose signature migrations begin because it pairs a comfortable category-3 margin with sizes that certificate ecosystems and software-signing pipelines can absorb. It is the signature-side counterpart to ML-KEM-768: the middle tier that most guidance treats as the sensible starting point rather than the constrained-case floor or the maximum-assurance ceiling. The reasons it became the practical default:
- Comfortable margin. Category 3 provides strong post-quantum assurance for general-purpose signing without reaching for the highest tier.
- Manageable artifacts. Its keys and signatures are large but tolerable in modern certificate chains and code-signing workflows, where the largest post-quantum signatures start to strain transport and storage.
- Ecosystem momentum. It is the parameter set most early PQC signature deployments and analyses use, which means the most tested tooling and the best interoperability.
For mission-assurance roles like long-lived roots of trust and firmware, SLH-DSA is the conservative hash-based alternative, and for the highest lattice tier there is ML-DSA-87. ML-DSA-65 remains the general-purpose default that most estates deploy first.
Source: NIST FIPS 204, Tables 1 and 2, August 2024.
What does deploying ML-DSA-65 actually look like?
The compute is realistic on mainstream hardware; the work is absorbing bigger artifacts into systems built around small elliptic-curve signatures. The friction shows up in a few predictable places. Certificates grow, so larger keys and signatures can stress certificate chains, parsers, transport limits, and validation logic that assumed classical dimensions. Code signing is usually fine, but the packaging, manifest, and metadata systems around it still need testing. Verifiers are the long pole, because a signature is only useful if every relevant verifier can process it, and trust stores, certificate authorities, and HSM workflows often lag the standard.
Like ML-KEM-768, ML-DSA-65 typically enters as a swappable cryptographic provider rather than application code, through the Open Quantum Safe provider on OpenSSL or the BouncyCastle provider in Java, so applications rarely change directly. That is crypto-agility doing its job. The recurring theme matches the KEM side: switching to ML-DSA-65 is rarely a compile-time change, it is a certificate, verifier, and lifecycle project.
Common misconceptions
- “The 65 means a 65-bit or 65-byte key.” It does not. The number reflects the dimensions of the internal lattice matrix and maps to security category 3, not to a key or signature length. The signature is 3,309 bytes.
- “ML-DSA-65 is the answer to everything post-quantum.” It is the general-purpose signature default, not a universal answer. Key establishment is ML-KEM’s job, and specialized roles like firmware roots of trust may be better served by SLH-DSA.
- “Finalized standard means fully mature ecosystem.” FIPS 204 is final, but verifier support, certificate-authority tooling, and HSM workflows are still catching up. Present in a library is not the same as enabled and tested end to end in production.
- “It’s a drop-in for ECDSA.” Same role, very different dimensions. Its nearly-two-kilobyte public key and 3,309-byte signature ripple into certificates, parsers, and trust stores, so it is a planned migration, not a swap.
Questions people ask
Why is ML-DSA-65 the default and not ML-DSA-44 or ML-DSA-87? It balances a comfortable category-3 margin against artifacts that certificate and signing systems can absorb, which is where most general-purpose signature migrations start. ML-DSA-44 is the lighter category-2 option and ML-DSA-87 is the category-5 maximum.
How big are ML-DSA-65’s artifacts? Its public key is 1,952 bytes, its signature is 3,309 bytes, and its private key is 4,032 bytes.
Does ML-DSA-65 do key exchange? No. It is a signature algorithm, so it proves authenticity and integrity only. Key establishment is the job of ML-KEM.
When should I pick SLH-DSA over ML-DSA-65? For long-lived roots of trust and firmware signing, where a conservative, non-lattice foundation is worth its larger signatures. For general-purpose, high-volume signing, ML-DSA-65 is the better first choice.
Is ML-DSA-65 the same as Dilithium? ML-DSA is the standardized successor to the competition scheme CRYSTALS-Dilithium. The canonical, citable name is ML-DSA-65 (FIPS 204); Dilithium is the research-era name.
Everything here is the map, given freely. When your team needs ML-DSA-65 sized and sequenced into your own signing infrastructure, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.