up:: Digital Signature
ML-DSA vs SLH-DSA vs FN-DSA
What is the difference between ML-DSA, SLH-DSA and FN-DSA?
All three prove authenticity and integrity, and they differ enormously in size and in what they hedge against. ML-DSA is the balanced general-purpose standard. SLH-DSA trades a very large signature for a foundation that no lattice break can touch. FN-DSA produces by far the smallest signature and is not yet an approved standard.
The short version:
- ML-DSA is the default. Finalized in FIPS 204, August 2024, and the scheme most migration guidance starts from.
- SLH-DSA is the conservative hedge. Finalized in FIPS 205, August 2024, and the only one of the three that is not lattice-based.
- FN-DSA is the compact option and it is still in development. FIPS 206 is unfinished, so it is a planning target rather than a compliance answer.
- The size spread is the whole decision. At their lowest tiers, signatures run 666 bytes for FN-DSA, 2,420 for ML-DSA and 7,856 for SLH-DSA, while public keys run 32 bytes for SLH-DSA against 1,312 for ML-DSA.
- Signatures are a different job from key establishment. For that, see ML-KEM vs HQC.
What is ML-DSA?
The primary NIST post-quantum signature standard, FIPS 204, finalized August 2024, known during the competition as CRYSTALS-Dilithium. It rests on Module-LWE, the same lattice family behind ML-KEM.
It is the common general-purpose starting default. Its parameter sets are ML-DSA-44 at category 2, ML-DSA-65 at category 3, and ML-DSA-87 at category 5.
What is SLH-DSA?
The hash-based signature standard, FIPS 205, finalized August 2024, known during the competition as SPHINCS+. Its security rests only on the strength of a hash function, which is the most conservative assumption available in this field.
It defines 12 parameter sets, from three security categories multiplied by a SHA2 or SHAKE variant and a small-signature or fast-signing tuning. Public keys are tiny and signatures are very large.
What is FN-DSA?
The forthcoming FALCON-derived standard, FIPS 206, which is still in development. It rests on NTRU lattices, a different lattice construction from ML-DSA’s.
Its defining trait is compactness, producing the smallest signature of any standardization-track post-quantum scheme. It has two parameter sets, FN-DSA-512 at category 1 and FN-DSA-1024 at category 5, with no category-3 option.
The three at a glance
Compared at each scheme’s lowest parameter set, since the tiers do not align cleanly.
| Dimension | ML-DSA-44 | FN-DSA-512 | SLH-DSA-128s |
|---|---|---|---|
| Standard | FIPS 204, finalized August 2024 | FIPS 206, in development. Not approved | FIPS 205, finalized August 2024 |
| Security category | Category 2 | Category 1 | Category 1 |
| Mathematical basis | Module-LWE lattice | NTRU lattice | Hash-based. No lattice assumption |
| Public key | 1,312 bytes | 897 bytes | 32 bytes |
| Private key | 2,560 bytes | Not stated in this Guide | Not stated in this Guide |
| Signature | 2,420 bytes | 666 bytes | 7,856 bytes |
| Competition name | CRYSTALS-Dilithium | FALCON | SPHINCS+ |
| Parameter sets | 3, at categories 2, 3 and 5 | 2, at categories 1 and 5. No category 3 | 12, across 3 categories with SHA2/SHAKE and small/fast variants |
| Usable for compliance today | Yes | No. The standard is unfinished | Yes |
For scale on the middle tier, ML-DSA-65 at category 3 has a 1,952-byte public key and a 3,309-byte signature. For contrast, a classical elliptic-curve public key is 32 bytes.
Sources: NIST FIPS 204, Tables 1 and 2, August 2024. NIST FIPS 205, Table 2, August 2024. FN-DSA figures from the FALCON specification and the NIST post-quantum project page, with FIPS 206 still in development, as carried in FN-DSA-512.
How do they actually differ?
⭐ Two of the three are lattice schemes, and that is the most important line in this comparison.
ML-DSA rests on Module-LWE and FN-DSA rests on NTRU. Those are different constructions and they are both lattices. SLH-DSA is the only standardized signature scheme on a genuinely independent foundation, resting on hash-function security alone. It occupies the same role in the signature lane that HQC occupies in the key-establishment lane: the hedge against a break in lattice mathematics reaching the whole migration at once.
The size tradeoffs run in opposite directions and eliminate options in real protocols.
FN-DSA has the smallest signature by a wide margin, 666 bytes against ML-DSA’s 2,420 and SLH-DSA’s 7,856. Where a protocol field or a packet budget constrains signature size, that difference decides the matter rather than informing it.
SLH-DSA has the smallest public key by a wide margin, 32 bytes against 1,312. Where many public keys are stored or distributed and signatures are rare, the arithmetic inverts.
And the standardization gap is the constraint most often overlooked. ML-DSA and SLH-DSA are finalized federal standards. FIPS 206 is unfinished, so FN-DSA cannot answer a compliance requirement today regardless of how well its size profile fits.
Where do they agree?
All three do signatures, proving authenticity and integrity, and none of them establishes a key. Key establishment is ML-KEM’s job, and conflating the two is the most common error in this subject.
All three are far larger than what they replace. A classical elliptic-curve public key is 32 bytes and an ECDSA signature is a small fraction of any figure in the table.
All three address the same threat, which is Shor’s algorithm breaking ECDSA and RSA signatures.
And none of them is deployed at scale. Published measurement finds no post-quantum certificate signatures at any measured endpoint, so the authentication lane remains classical almost everywhere.
When is ML-DSA the right answer?
Where a finalized standard and a balanced size profile are both required, which describes most general-purpose signing. It is the scheme migration guidance starts from and the one regulators reference.
When is SLH-DSA the right answer?
Where the requirement is a foundation independent of lattices, or where public keys are numerous and signatures are rare, or where the signing is infrequent enough that a very large signature is affordable. Firmware and code signing are the shapes that fit.
It is also the conservative answer for anything with a very long verification horizon, since hash-function security is the assumption the field trusts most.
When is FN-DSA the right answer?
Where signature size is the binding constraint, which happens in protocols with fixed fields and in bandwidth-constrained links. The condition that currently rules it out is compliance, because FIPS 206 is unfinished and there is no approved standard to point at.
Why did NIST standardize more than one?
Because a single signature scheme concentrates two different risks at once.
The mathematical risk is that lattices carry both the primary KEM and the primary signature, so an advance against lattices would reach most of the migration together. SLH-DSA answers that.
The engineering risk is that no single size profile fits every protocol. A 2,420-byte signature is unremarkable in a web handshake and impossible in a constrained field, so a portfolio covers cases one scheme cannot.
Is one replacing the other?
No. They are complements sized for different constraints, and the published position treats ML-DSA as the general-purpose default with the others available where their profiles fit.
Common misconceptions
“FN-DSA is available now.” FIPS 206 is still in development. It is a planning and prototyping target rather than an approved standard.
“SLH-DSA is the most secure.” It is the most conservative in its assumption, resting only on hash-function security. Security category is a separate axis, and all three cover multiple categories.
“Bigger signatures mean stronger.” Size reflects the construction rather than the security margin. SLH-DSA-128s and FN-DSA-512 are both category 1 and differ by a factor of nearly 12 in signature size.
“ML-DSA and FN-DSA are unrelated options.” Both are lattice schemes. Choosing between them is not basis diversification.
“We can pick one and be done.” Protocols with different size constraints may need different schemes, which is why the portfolio exists.
Questions people ask
Which should I use? Published guidance treats ML-DSA as the general-purpose default. This page teaches the distinctions rather than selecting for a particular estate.
Which has the smallest signature? FN-DSA-512 at 666 bytes, and it is not yet an approved standard.
Which has the smallest public key? SLH-DSA, at 32, 48 or 64 bytes depending on category.
Which is the safest bet if lattices break? SLH-DSA, since it carries no lattice assumption. ML-DSA and FN-DSA are both lattice schemes.
Why does FN-DSA have no category-3 option? Its two parameter sets target categories 1 and 5. An estate standardizing on category 3 across its cryptography has no matching FN-DSA set.
Why does SLH-DSA have 12 parameter sets? Three security categories, each in a SHA2 and a SHAKE variant, each in a small-signature or fast-signing tuning. See SLH-DSA parameter sets.
Are any of these deployed? Measurement of 4,665 organizations found no post-quantum certificate signatures at any endpoint. The authentication lane has not started migrating in public deployment.
Do regulators require a specific one? Federal guidance references the finalized standards, which are ML-DSA and SLH-DSA. FN-DSA is not finalized and therefore does not appear as a requirement.
Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs. Work with Addie at lamarrlabs.com.