ML-DSA vs SLH-DSA: Which to Choose

Cryptography

ML-DSA vs SLH-DSA: Choosing Your Signature Algorithm

14 min read

What Are Digital Signatures, and Why Should You Care?

Imagine you receive a letter in the mail. How do you know who actually sent it? Someone could have forged the return address. How do you know nobody opened the envelope, changed a few words, and resealed it? In the physical world, we have notaries, wax seals, and registered mail. In the digital world, we have digital signatures.

A digital signature is a piece of math attached to a file or message that proves two things. First, authenticity: the file genuinely came from the person or organization claiming to have sent it. Second, integrity: the file has not been changed, even by a single bit, since it was signed. If someone modifies the file after signing, the signature check fails.

You rely on digital signatures constantly, even if you never think about them. Every time your phone installs a software update, it checks a digital signature to confirm the update came from Apple or Google, not a hacker. Every time your browser connects to your bank, it verifies a chain of digital signatures on the bank's security certificate. Every time a hospital transfers a medical record, signatures confirm the data has not been tampered with.

The problem is that the digital signature algorithms we have used for decades (RSA, ECDSA, EdDSA) will all be broken by a sufficiently powerful quantum computer. A quantum algorithm called Shor's algorithm can solve the underlying math problems in hours instead of billions of years. The signatures that protect software updates, financial transactions, and medical records will become forgeable.

NIST (the U.S. National Institute of Standards and Technology) spent eight years evaluating replacement algorithms that quantum computers cannot break. In August 2024, they published two post-quantum signature standards: ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). Both are quantum-safe. Both are NIST-approved. But they work in fundamentally different ways, with different tradeoffs. Choosing between them matters.

ML-DSA: The Fast, General-Purpose Option

ML-DSA stands for Module-Lattice Digital Signature Algorithm. It was standardized as NIST FIPS 204 in August 2024. During NIST's evaluation process, it was known by its competition name, CRYSTALS-Dilithium.

The word "lattice" refers to the mathematical structure that makes ML-DSA secure. Think of a lattice as a grid of points in space. In two dimensions, a lattice is like graph paper: an orderly grid of dots. Now imagine that grid extended into hundreds of dimensions. In such a high-dimensional lattice, certain problems become extremely hard to solve. Specifically, given a random point somewhere near the lattice, finding the closest actual lattice point is a problem that neither classical nor quantum computers can solve efficiently. This is called the "Closest Vector Problem," and ML-DSA's security depends on a related problem called Module Learning With Errors (MLWE).

What does this mean in practice? ML-DSA is fast. A modern computer can generate thousands of signatures per second with ML-DSA. Verification is even faster. Keys and signatures are relatively compact compared to other post-quantum schemes. This makes ML-DSA a natural fit for high-volume applications: web servers handling thousands of TLS connections, code signing pipelines processing hundreds of software releases, or data encryption tools signing documents one after another.

ML-DSA comes in three security levels, each with different key and signature sizes:

Variant	NIST Security Level	Signature Size	Public Key Size	Private Key Size
ML-DSA-44	Level 2 (128-bit)	2,420 bytes	1,312 bytes	2,560 bytes
ML-DSA-65	Level 3 (192-bit)	3,293 bytes	1,952 bytes	4,032 bytes
ML-DSA-87	Level 5 (256-bit)	4,627 bytes	2,592 bytes	4,896 bytes

The numbers (44, 65, 87) refer to the internal matrix dimensions used by the algorithm. Higher numbers mean larger keys and signatures, but also higher security margins. ML-DSA-44 provides security comparable to AES-128, which is considered strong enough for most applications today. ML-DSA-87 provides security comparable to AES-256, which is what governments use for top-secret information.

NIST designates ML-DSA as their primary recommendation for general-purpose digital signatures. If you need a post-quantum signature algorithm and have no specific reason to choose something else, ML-DSA is the default answer.

SLH-DSA: The Ultra-Conservative Backup

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. It was standardized as NIST FIPS 205 in August 2024. During the NIST evaluation, it was known as SPHINCS+.

SLH-DSA takes a completely different approach to security. Instead of relying on lattice mathematics, it relies entirely on hash functions: the same kind of cryptographic functions used in password storage, blockchain, and data integrity checks. Hash functions take any input and produce a fixed-size output (a "digest"). They have three critical properties: you cannot reverse them (given the output, you cannot figure out the input), you cannot find two different inputs that produce the same output, and changing even one bit of the input completely changes the output.

Why does this matter? Hash functions are some of the most studied and best-understood tools in all of cryptography. The SHA family of hash functions has been scrutinized by thousands of researchers for over two decades. We have a deep, mature understanding of what makes hash functions secure. Lattice problems, by comparison, are newer to cryptography. They have been studied seriously since the late 1990s, but that is significantly less time than hash functions have been under the microscope.

SLH-DSA's internal structure combines three building blocks, all constructed purely from hash functions:

• WOTS+ (Winternitz One-Time Signatures): A scheme that can sign a single message using only hash chains. You start with a secret value and hash it repeatedly; the number of times you hash encodes the message bits.
• FORS (Forest of Random Subsets): A few-time signature scheme that signs short messages by revealing selected leaves from multiple small trees of hash values.
• Hypertree: A tree of Merkle trees that chains together many WOTS+ instances, allowing the single public key (the root hash) to authenticate a large number of one-time keys.

The result is a signature algorithm whose security depends on exactly one assumption: that the underlying hash function (SHA-256 or SHAKE256) behaves like a secure hash function. No lattice math. No number theory. No algebraic structure. Just hashing. If the hash function is good, the signatures are unforgeable. Period.

How does this compare to LMS, the other hash-based signature scheme? LMS (standardized in NIST SP 800-208) is also hash-only, but it is stateful: each signature uses up a "leaf" in a Merkle tree, and the key has a fixed maximum number of signatures. SLH-DSA is stateless: you can sign as many times as you want with the same key, just like ML-DSA. The statefulness of LMS makes it simpler and produces smaller signatures, but requires careful tracking of which leaves have been used. SLH-DSA trades larger signatures for the convenience of not having to manage state. For most users, stateless operation is strongly preferred.

The tradeoff for this simplicity is size. SLH-DSA signatures are much larger than ML-DSA signatures:

Variant	NIST Security Level	Signature Size	Public Key Size	Speed (f vs s)
SLH-DSA-128f	Level 1 (128-bit)	17,088 bytes	32 bytes	Fast signing
SLH-DSA-128s	Level 1 (128-bit)	7,856 bytes	32 bytes	Slow signing, smaller sig
SLH-DSA-192f	Level 3 (192-bit)	35,664 bytes	48 bytes	Fast signing
SLH-DSA-256f	Level 5 (256-bit)	49,856 bytes	64 bytes	Fast signing

Notice the "f" and "s" suffixes. Each SLH-DSA security level comes in two flavors: "f" (fast) optimizes for signing speed at the cost of larger signatures, while "s" (small) produces smaller signatures but takes significantly longer to sign. Even the "fast" variants are slower than ML-DSA for signing, though verification speed is reasonable.

Also notice the public key sizes: 32 to 64 bytes. SLH-DSA has the tiniest public keys of any post-quantum signature scheme. The public key is just a hash value. This can be useful in systems where public keys are stored long-term or distributed widely.

Head-to-Head Comparison

Here is a direct comparison between ML-DSA and SLH-DSA across the dimensions that matter most:

Property	ML-DSA (FIPS 204)	SLH-DSA (FIPS 205)
Security basis	Module-LWE lattice problem	Hash function security only
Signature size (128-bit security)	2,420 bytes	7,856 - 17,088 bytes
Public key size (128-bit security)	1,312 bytes	32 bytes
Signing speed	Very fast (thousands/sec)	Slower (tens to hundreds/sec)
Verification speed	Very fast	Moderate
Years of cryptanalysis on underlying math	~25 years (lattices since late 1990s)	~30+ years (hash functions since early 1990s)
NIST recommendation	Primary general-purpose standard	Conservative backup standard
NIST standard number	FIPS 204	FIPS 205
Stateless?	Yes	Yes

The core tradeoff is clear. ML-DSA gives you speed and compactness, built on lattice math that is well-studied but newer to cryptography. SLH-DSA gives you the most conservative security guarantee possible, built on hash functions that have been analyzed for decades, but your signatures will be 7x to 20x larger.

Why NIST Standardized Both

If ML-DSA is faster and more compact, why did NIST bother standardizing SLH-DSA at all? The answer is algorithm diversity, and it is a principle that the cryptographic community takes very seriously.

Every cryptographic algorithm is a bet on a mathematical problem being hard to solve. ML-DSA bets on lattice problems. If someone discovers an efficient algorithm for solving lattice problems (classical or quantum), ML-DSA breaks. That would be a catastrophe if ML-DSA were the only post-quantum signature standard, because every system that adopted it would be vulnerable simultaneously.

SLH-DSA bets on hash functions. A breakthrough against lattice problems would not affect SLH-DSA at all. The two algorithms fail independently. By standardizing both, NIST ensures that the world has a ready-made fallback if lattice-based cryptography is ever compromised. Organizations can deploy SLH-DSA as a second line of defense, or use it for their most sensitive, longest-lived signatures while using ML-DSA for everyday operations.

This is the same philosophy behind hybrid encryption: do not put all your trust in one mathematical assumption. NIST explicitly designed the post-quantum standards portfolio to include algorithms from multiple mathematical families so that no single breakthrough can break everything.

When to Choose ML-DSA

ML-DSA is the right choice for the majority of applications. Choose it when:

• You need speed. Web servers, API gateways, and CI/CD pipelines that sign or verify thousands of items per second will benefit from ML-DSA's performance. Signing and verification are both extremely fast.
• Bandwidth matters. If signatures are transmitted over a network (TLS handshakes, certificate chains, IoT devices on cellular connections), ML-DSA's 2.4 KB signatures are far more practical than SLH-DSA's 17+ KB signatures.
• Storage is a concern. If you are signing millions of software packages, database records, or audit log entries, the per-signature storage cost adds up. ML-DSA keeps that cost low.
• You want NIST's primary recommendation. NIST explicitly positions ML-DSA as the default post-quantum signature algorithm. Compliance frameworks that reference NIST standards will default to ML-DSA.

When to Choose SLH-DSA

SLH-DSA is the right choice when the conservative security guarantee outweighs the size and speed costs. Choose it when:

• Signatures must be verifiable for decades. If you are signing legal documents, property records, or archival medical records that need to hold up 30 or 50 years from now, SLH-DSA's hash-only security basis provides the strongest assurance that the signatures will still be valid.
• You need a hedge against lattice breakthroughs. If your organization's threat model considers the possibility that lattice-based cryptography could be weakened by future research, SLH-DSA provides an independent safety net.
• Regulatory requirements demand algorithm diversity. Some compliance frameworks require using algorithms from at least two distinct mathematical families. SLH-DSA satisfies this when paired with lattice-based ML-DSA.
• Signature size is acceptable. Firmware images, software releases, and large documents can easily absorb an extra 15-50 KB of signature data without meaningful impact.
• You want the smallest possible public keys. SLH-DSA's 32-64 byte public keys are ideal for systems where public keys are stored on constrained devices or embedded in certificates that are cached long-term.

The Quantum Threat to Signatures: Why This Matters Now

You might wonder why you should care about post-quantum signatures today, when large-scale quantum computers do not exist yet. The answer depends on whether you care about the past or just the present.

For encryption, the threat is immediate because of "harvest now, decrypt later" attacks. Adversaries record encrypted data today and store it until quantum computers can decrypt it. For signatures, the threat is different but equally serious. Once quantum computers exist, an attacker could forge signatures on firmware updates, software packages, legal documents, and certificates. If your system trusts signatures created with RSA or ECDSA, a quantum-capable attacker could impersonate any signer, modify any signed document, and inject malicious code into any signed software update.

Migrating to ML-DSA or SLH-DSA now means that the signatures you create today will still be trustworthy in the quantum era. Signatures on legal documents, medical records, and archival materials need to be verifiable for decades. Starting the migration now protects the long-term integrity of everything you sign.

Real-World Use Cases

Hospital Medical Records

A hospital system that signs patient records should use ML-DSA for day-to-day operations: fast signing, compact signatures, minimal overhead on already-complex healthcare IT systems. For long-term archival records that may need to be verified 30+ years later, the hospital might use SLH-DSA to ensure the signatures remain trustworthy regardless of future advances in attacking lattice problems.

Software Distribution

A software company signing thousands of packages per day for distribution to millions of users should use ML-DSA. The combination of fast signing, fast verification, and compact signatures keeps the distribution pipeline efficient. Every extra kilobyte in a signature is multiplied by millions of downloads.

Root Certificate Authorities

A certificate authority that signs a root certificate once every 10-20 years might choose SLH-DSA for that root signature, since it will need to be trusted for decades and the signature is only generated once. Intermediate certificates, signed more frequently, could use ML-DSA.

QNSQY's Approach

QNSQY provides both algorithms, and combines them with classical cryptography for defense-in-depth:

• Hybrid ML-DSA + Ed25519: The default signing mode. Your file gets both a post-quantum signature (ML-DSA) and a classical signature (Ed25519). An attacker would need to break both to forge a signature. Available on Pro tier and above.
• SLH-DSA options: All six SLH-DSA parameter sets (128/192/256, f/s) are available on Pro tier. Choose the security level and speed/size tradeoff that fits your needs.
• ML-DSA-44 (Free tier): Basic quantum-safe signing is available to everyone at no cost, with no file size restrictions.

For most users, the hybrid ML-DSA + Ed25519 mode is the right default. It provides both post-quantum and classical security with minimal overhead. Switch to SLH-DSA when you need the most conservative security guarantee available, and the larger signatures are acceptable for your use case.

The Short Version

Question	ML-DSA	SLH-DSA
Is it quantum-safe?	Yes	Yes
Is it NIST-approved?	Yes (FIPS 204)	Yes (FIPS 205)
Is it fast?	Very	Moderate
Are signatures compact?	Yes (2.4 - 4.6 KB)	No (7.8 - 49.9 KB)
Is the security assumption conservative?	Good (lattices)	Best possible (hash functions only)
Best for?	Everyday signing, high volume	Long-term archival, maximum assurance

Sources

1. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA), August 2024
2. NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA), August 2024
3. NIST IR 8413: Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process, September 2022
4. NIST Post-Quantum Cryptography Project Page

Related Articles

• FN-DSA (Falcon): Compact PQ Signatures
• ML-KEM: Future of Key Encapsulation
• NIST FIPS 203/204/205: The Complete Guide

Sign Your Files with Confidence

QNSQY Pro includes both ML-DSA and SLH-DSA signing options. Business adds FN-DSA (Falcon) and LMS.

View Pricing

---

Originally published at quantumsequrity.com.