Hadamard Get the app

ML-DSA vs SLH-DSA: Signature Sizes, Speed and Which to Use

ML-DSA vs SLH-DSA: Signature Sizes, Speed and Which to Use — Hadamard

ML-DSA (FIPS 204) is NIST’s primary post-quantum signature. It is lattice-based and fast, and its smallest signatures are 2,420 bytes. SLH-DSA (FIPS 205) is the hash-based backup: its public keys are only 32 to 64 bytes, but its signatures run from 7,856 to 49,856 bytes and take far longer to create. That trade-off makes ML-DSA the default for TLS and high-volume signing, while SLH-DSA suits firmware, software releases and long-lived roots, where a conservative security assumption matters more than speed.

This ML-DSA vs SLH-DSA comparison covers exact sizes for every parameter set, relative speed, why NIST standardized two signatures, and what has changed since the standards were finalized, including the SP 800-230 draft published in April 2026.

ML-DSA vs SLH-DSA at a glance: two standards, two kinds of math

NIST published FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) as final standards on August 13, 2024, almost a year after the drafts appeared on August 24, 2023. According to the Federal Register notice, “FIPS 203, FIPS 204, and FIPS 205 are effective on August 14, 2024.”

The two rest on different foundations. In its announcement, NIST says ML-DSA is module-lattice-based, derived from CRYSTALS-Dilithium, and serves as the primary signature standard. SLH-DSA is hash-based and derived from SPHINCS+. NIST describes it as “intended as a backup method in case ML-DSA proves vulnerable,” built on a different mathematical approach.

The FIPS 205 abstract describes SLH-DSA as a stateless hash-based digital signature algorithm whose signatures detect unauthorized changes, authenticate the signer and provide non-repudiation. ML-DSA offers the same properties. What differs is the assumption underneath: lattice problems for ML-DSA, and only the security of the hash function for SLH-DSA.

ML-DSA vs SLH-DSA signature size, byte for byte

Size is usually the first constraint engineers hit. The ML-DSA figures below come from RFC 9881, the IETF Proposed Standard for ML-DSA in X.509 certificates and CRLs. They are raw sizes, without ASN.1 overhead.

ML-DSA set Signature Public key Private key (seed) Private key (expanded)
ML-DSA-44 2,420 B 1,312 B 32 B 2,560 B
ML-DSA-65 3,309 B 1,952 B 32 B 4,032 B
ML-DSA-87 4,627 B 2,592 B 32 B 4,896 B

SLH-DSA has twelve parameter sets: six sizes, each available with SHA2 or SHAKE. RFC 9909 lists the sizes, which are the same for both hash families and for both Pure and HashSLH-DSA.

SLH-DSA set NIST level Signature Public key Private key
128s 1 7,856 B 32 B 64 B
128f 1 17,088 B 32 B 64 B
192s 3 16,224 B 48 B 96 B
192f 3 35,664 B 48 B 96 B
256s 5 29,792 B 64 B 128 B
256f 5 49,856 B 64 B 128 B

How they compare with Ed25519 and RSA-2048

Cloudflare’s comparison by Bas Westerbaan and Luke Valenta gives the classical baseline. Ed25519 has a 32-byte public key and a 64-byte signature, and RSA-2048 uses 256 bytes for each. An ML-DSA-44 signature is therefore about 38 times larger than an Ed25519 signature. An SLH-DSA-128s signature is more than 120 times larger.

The two schemes fail on size in different ways. ML-DSA’s public keys and signatures are both large; as Cloudflare puts it, “The big downside is that its signatures and public keys are large.” SLH-DSA’s public key is as small as Ed25519’s, but almost all of its cost sits in the signature.

How fast are ML-DSA and SLH-DSA?

Cloudflare normalized CPU time to ML-DSA-44 = 1. These are rough ratios, and the post warns that “CPU performance varies significantly by platform and implementation.”

  • SLH-DSA-128s: signing about 14,000x, verification about 40x
  • Ed25519: signing about 0.15x, verification about 1.3x
  • RSA-2048: signing about 80x, verification about 0.4x

ML-DSA is therefore in the same performance range as the classical schemes it replaces. SLH-DSA signing is orders of magnitude slower. That is acceptable when you sign one firmware image per release, but not when a server signs on every connection.

What “s” and “f” mean

Each SLH-DSA security level comes in two forms. According to RFC 9909, the “s” (small) sets are optimized for signature size. The “f” (fast) sets sign and generate keys faster, but verify more slowly and roughly double the signature size. At level 1, for example, 128s produces 7,856-byte signatures and 128f produces 17,088-byte signatures.

Why did NIST standardize a backup signature?

Lattice cryptography is efficient, but its security rests on mathematical problems that are newer to cryptanalysis than hash functions are. NIST’s stated reason for SLH-DSA is to hedge against that risk: if a structural attack on lattices breaks ML-DSA, a standardized signature based on different math already exists. SLH-DSA’s security depends only on its hash functions, and the field has long experience with how hash functions weaken over time. Our article on how SHA-1 went from a theoretical break to a practical collision traces one example.

NIST also explained why it did not hold the standards back. Dustin Moody, the NIST mathematician who heads the PQC standardization project, said: “There is no need to wait for future standards.” The same announcement names FN-DSA (FIPS 206, based on FALCON) as a forthcoming third signature standard.

What NIST changed and declined to change

NIST’s responses to public comments in the Federal Register notice record several design decisions:

  • A randomized ML-DSA variant “could enable more efficient side-channel protections,” but NIST did not adopt it because implementations would be harder to validate.
  • For SLH-DSA, proposed SHA-256/SHA-512 variants and a switch from SHAKE256 to TurboSHAKE256 were rejected because “the improvements were not considered significant enough” to justify using primitives not currently specified in NIST standards.
  • NIST said it “intends to propose” SLH-DSA parameter sets with smaller signatures and signature limits below 2^64 in a separate Special Publication. That publication is now SP 800-230.

SLH-DSA vs stateful LMS and XMSS

SLH-DSA was not NIST’s first hash-based signature recommendation. NIST SP 800-208, finalized on October 29, 2020, specifies LMS and XMSS and their multi-tree variants, HSS and XMSS-MT. Those schemes are stateful: the signer has to track which one-time keys have already been used. SLH-DSA is stateless, so the signer does not have to keep that record.

This difference matters in practice. With a stateful scheme, restoring a key from backup or cloning it across machines can lead to an index being reused, which undermines security. SLH-DSA avoids that failure mode in exchange for larger signatures. Even so, it has a usage ceiling: RFC 9909 notes that each private key is limited to about 2^64 signatures and advises operators to track usage or set validity periods so the limit cannot be reached.

SP 800-230: smaller SLH-DSA parameter sets capped at 2^24 signatures

NIST published SP 800-230, “Additional SLH-DSA Parameter Sets for Limited-Signature Use Cases,” as an Initial Public Draft on April 13, 2026. The comment period closed on June 12, 2026, and NIST has posted the comments it received. The document is still a draft.

The draft adds six parameter sets at security levels 1, 3 and 5. They aim at faster verification and smaller signatures for software, firmware and certificate signing. In exchange, each signing key is capped at 2^24 signatures, and the sets are “not approved for general-purpose use.” Users must make sure the limit is never exceeded.

A cap of 2^24 is about 16.8 million signatures. That is plenty for a firmware vendor or a root CA and far too few for a busy TLS endpoint. The approach brings back some of the discipline of stateful schemes, because you have to count signatures, but a single slip does not carry the immediate risk of reusing an LMS or XMSS index.

ML-DSA or SLH-DSA: which should you use?

The sizes and speeds above point to a fairly clear split.

TLS, certificates and high-volume signing: ML-DSA

Handshakes carry several signatures and public keys, and servers sign constantly. According to Cloudflare, SLH-DSA-128s would add about 39 kB to a TLS handshake, and its signing cost is in the thousands of times ML-DSA’s. ML-DSA-44 or ML-DSA-65 is the practical choice here. Key exchange is a separate problem; our explainer on X25519MLKEM768 in TLS 1.3 covers that side.

Firmware, software releases and long-lived roots: SLH-DSA

When you sign rarely, verify often and need the key to stay trustworthy for many years, SLH-DSA’s conservative assumption pays off. Slow signing hardly matters for a monthly release, and a 32-byte public key is easy to burn into a boot ROM. Choose “s” sets when the signature is stored or transmitted many times.

Deployment details from RFC 9909

  • CAs must choose Pure SLH-DSA or HashSLH-DSA in advance, because the choice is tied to the OID.
  • Pure SLH-DSA needs the whole message in memory, which can exceed HSM input limits for large CRLs. HashSLH-DSA reduces this problem.
  • Track signature counts against the roughly 2^64 limit, and against 2^24 if you adopt SP 800-230 sets once they are final.

For the dates that drive these migrations, see NIST IR 8547’s deprecation deadlines for RSA and ECC. Our post-quantum migration tracker follows how standards and platforms are adopting the new algorithms.

Hash-based designs are also being used outside PKI. Hadamard builds BB84, an ECDSA-free Layer 2 rollup on Ethereum. Its accounts are one-time addresses based on hash commitments instead of ECDSA keys, so the design relies on hash functions, the same kind of assumption that makes SLH-DSA the conservative choice.

FAQ

Is SLH-DSA more secure than ML-DSA?

Not in any simple sense. The two rely on different assumptions: SLH-DSA on hash functions, ML-DSA on lattice problems. NIST calls ML-DSA the primary standard and SLH-DSA a backup in case ML-DSA proves vulnerable. SLH-DSA is a hedge, not an upgrade.

Why are post-quantum signatures so much bigger than Ed25519?

The schemes rely on different mathematics, which leads to larger outputs. Ed25519 signatures are 64 bytes, compared with 2,420 bytes for ML-DSA-44 and 7,856 bytes for SLH-DSA-128s. ML-DSA also has a 1,312-byte public key, while SLH-DSA keeps the public key at 32 bytes and puts the cost into the signature.

Should I use the “s” or “f” SLH-DSA parameter sets?

Use “s” when signature size matters and signing is infrequent, which covers most firmware and code signing. Use “f” when signing or key generation speed is the bottleneck and you can accept signatures roughly twice as large and slower verification.

How does SLH-DSA differ from LMS/XMSS, and what does SP 800-230 change?

LMS and XMSS (SP 800-208) are stateful, so the signer must never reuse a one-time key index. SLH-DSA is stateless. The SP 800-230 draft adds smaller-signature SLH-DSA sets limited to 2^24 signatures per key, intended for limited-signature uses rather than general-purpose signing.

Sources