up:: FIPS 205 (SLH-DSA)

SLH-DSA parameter sets

SLH-DSA, the hash-based post-quantum signature scheme standardized in FIPS 205, defines twelve parameter sets, and understanding how they are organized is the whole job of this note. The twelve come from three choices multiplied together: three security categories (1, 3, and 5), two hash families (SHA2 and SHAKE), and two tunings within each category (s for small signatures and f for fast signing). The defining property across all of them is the same, tiny public keys of 32 to 64 bytes and very large signatures running from 7,856 bytes up to 49,856 bytes, so the choice among them is almost always a size-versus-speed decision made after the security category is fixed.

Source: NIST FIPS 205, Stateless Hash-Based Digital Signature Standard, Table 2, August 2024.

The short version:

• SLH-DSA does digital signatures, and every parameter set produces the same kind of signature with different size, speed, and security-category tradeoffs. Key establishment is ML-KEM’s job.
• The twelve sets are three security categories (1, 3, 5), each in a SHA2 and a SHAKE flavor, each tuned either s (small signature) or f (fast signing).
• Public keys are tiny, 32, 48, or 64 bytes, and signatures are very large, from 7,856 bytes at the smallest to 49,856 bytes at the largest.
• The s/f choice trades signature size against signing speed. It does not change the security category.
• The security category comes straight from the internal parameter n: n = 16 is category 1, n = 24 is category 3, n = 32 is category 5.

How are the twelve parameter sets organized?

Every SLH-DSA parameter set name encodes three decisions, and reading the name tells you exactly what it is. Take SLH-DSA-SHA2-192f as the worked example:

1. The hash family, SHA2 or SHAKE. This picks which underlying hash function drives the construction. The two flavors of a given tuple produce identical key and signature sizes and the same security category, so the choice is about which hash primitive an implementation or a policy prefers, not about size.
2. The security strength, 128, 192, or 256. This maps to NIST security categories 1, 3, and 5 respectively, and it comes directly from the internal security parameter n (16, 24, or 32 bytes).
3. The tuning, s or f. s means the set was tuned for a small signature and f for fast signature generation. Within one security category, the s set has the smaller signature and the slower signing, and the f set has the faster signing and the larger signature.

Three categories, times two hash families, times two tunings, gives the twelve sets. Because the SHA2 and SHAKE variants of a given tuple share the same sizes and category, the size table below lists the six size-distinct tuples and notes that each exists in both hash flavors.

Source: NIST FIPS 205, §11 and Table 2, August 2024.

What are the sizes and categories?

These figures are verbatim from Table 2 of the standard. Each row exists in both a SHA2 and a SHAKE variant with identical sizes.

Parameter set (SHA2 and SHAKE)	NIST security category	Public key	Signature	Tuning
SLH-DSA-128s	Category 1	32 bytes	7,856 bytes	small signature
SLH-DSA-128f	Category 1	32 bytes	17,088 bytes	fast signing
SLH-DSA-192s	Category 3	48 bytes	16,224 bytes	small signature
SLH-DSA-192f	Category 3	48 bytes	35,664 bytes	fast signing
SLH-DSA-256s	Category 5	64 bytes	29,792 bytes	small signature
SLH-DSA-256f	Category 5	64 bytes	49,856 bytes	fast signing

The security categories come straight from the parameter n: the n = 16 sets are claimed at category 1, n = 24 at category 3, and n = 32 at category 5. The security claim is existential unforgeability under chosen-message attack, and it holds as long as each key pair signs at most 2^64 messages. To put that ceiling in perspective, NIST notes that a key pair signing 10 billion messages every second would take over 58 years to reach 2^64, so for a firmware or root key that signs rarely the limit is effectively unreachable.

Source: NIST FIPS 205, Table 2 and §11, August 2024.

How do you choose between small and fast?

The s/f choice is the one that is unique to SLH-DSA, and it moves weight between two costs rather than removing it. Within a fixed security category, the small (s) set produces the smaller signature but signs more slowly, and the fast (f) set signs quicker but produces a larger signature. Neither choice makes SLH-DSA lightweight, because even the smallest set at category 1 is a 7,856-byte signature, more than a hundred times a classical ECDSA signature. The practical rule:

1. Choose s when the signature travels or is stored many times. Certificate chains, signed artifacts distributed widely, and anything where the byte count is paid repeatedly favor the small-signature tuning, and the slower signing is acceptable because signing happens rarely.
2. Choose f when signing throughput matters and the larger signature is affordable. Where the signing operation is on a hotter path and transport or storage can absorb the extra kilobytes, the fast tuning earns its size.

For most SLH-DSA roles, firmware and root-of-trust signing where signing is infrequent and long-term trust dominates, the small (s) sets are the natural fit, which is why they anchor the conservative use cases in the parent standard.

Source: NIST FIPS 205, §11, August 2024.

How does SHA2 differ from SHAKE here?

The SHA2 and SHAKE variants of a given tuple are functionally interchangeable on size and security category, and the difference is which hash primitive drives the internal construction. SHA2 sets build on the SHA-2 family, and SHAKE sets build on the SHAKE extendable-output functions from SHA-3. The choice usually follows an implementation’s existing hash acceleration or a policy preference for one family, not a size or margin difference, because a SHA2 set and its SHAKE twin carry the same public-key size, the same signature size, and the same claimed category. That symmetry is why the size table above lists six tuples rather than twelve rows.

Common misconceptions

1. “Hash-based means small and lightweight.” SLH-DSA carries the largest signatures in the standardized portfolio, from 7,856 to 49,856 bytes. Its public keys are tiny, but the signature is what dominates transport, storage, and every verifier.
2. “The s and f sets are different security levels.” They are not. Within a category the s and f sets share the same security claim. The s/f choice trades signature size against signing speed only.
3. “SHA2 and SHAKE variants have different sizes.” They do not. A tuple’s SHA2 and SHAKE variants carry identical public-key and signature sizes and the same category. The hash family is an implementation and policy choice.
4. “Bigger signature means stronger security.” The largest sets are the category-5 f sets, and their size comes from the fast tuning, not from a higher margin than the category-5 s set. Size within a category reflects the speed tradeoff, not the strength.

Questions people ask

How many SLH-DSA parameter sets are there? Twelve: three security categories, each in a SHA2 and a SHAKE hash flavor, each tuned s for small signatures or f for fast signing.

What do s and f mean? s is tuned for a small signature and slower signing; f is tuned for fast signing and a larger signature. The choice trades size against speed within a fixed security category.

Why are SLH-DSA signatures so large? The hash-based construction stacks many one-time and few-time signing pieces into a tree, and the signature carries the path through that tree. Even the smallest set is 7,856 bytes, and the largest is 49,856 bytes.

Do the SHA2 and SHAKE variants differ in size? No. A given tuple’s SHA2 and SHAKE variants have the same public-key size, the same signature size, and the same security category. They differ only in the underlying hash primitive.

How does the number in the name map to a security category? 128 is category 1, 192 is category 3, and 256 is category 5, driven by the internal parameter n of 16, 24, and 32 bytes respectively.

---

Everything here is the map, given freely. When your team needs the right SLH-DSA parameter set chosen against your own signing frequency, transport limits, and assurance policy, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.