SLH-DSA: A Practical Introduction to Hash-Based Signatures

On this page

Insights / Cryptographic engineering

What SLH-DSA is

SLH-DSA is the stateless hash-based digital signature algorithm specified in NIST FIPS 205. It is based on SPHINCS+. It provides signatures, rather than key establishment or encryption.

This guide explains the architecture and integration decisions. Use the standard’s exact algorithms and a suitable implementation for engineering work; the explanation here is not a reference implementation.

How the pieces fit

The design combines several layers:

• WOTS+ provides one-time signatures based on hash chains.
• XMSS trees authenticate WOTS+ public keys.
• A hypertree connects those trees to a single public root.
• FORS signs a digest-derived message; the hypertree authenticates the resulting FORS public key.

Signing produces a randomization string, a FORS signature, and a hypertree signature. Verification reconstructs the relevant public values and checks the result against the public root. The public key contains both a public seed and that root, so its length is 2n bytes, not n. See FIPS 205, Sections 3 and 9.

Choose a standard profile

FIPS 205 defines SHA2 and SHAKE families. Each offers profiles with a smaller-signature (s) or faster-signing (f) emphasis. Parameters belong to these complete standardized profiles; they should not be independently tuned as application configuration.

For example, the 128s profiles have a 32-byte public key and a 7,856-byte signature. The 128f profiles keep the 32-byte public key but use a 17,088-byte signature. These are signature-format sizes, not measurements of a particular implementation’s speed. FIPS 205, Table 2.

An engineering example: firmware verification

Consider a product that downloads a signed firmware manifest and verifies it on a constrained device. The following are design questions for that hypothetical product, not claims about a deployed system:

1. Transport: can the manifest format, protocol, and intermediary buffers carry the complete signature?
2. Verification budget: what happens to boot or update time on the slowest supported target?
3. Memory: can the selected implementation operate within the device’s actual memory limit?
4. Compatibility: how are algorithm identifiers, key versions, and unsupported clients handled?
5. Recovery: how does the device reject malformed or unsupported signatures without losing its recovery path?

A smaller signature can be valuable on a constrained transport even if signing takes longer on a well-provisioned release system. Conversely, a high-volume signing service may value a different profile. Measure the complete path, including parsing and storage, rather than extrapolating from a desktop cryptographic benchmark.

Implementation boundaries that matter

The standard specifies address handling, domain separation, message processing, and both internal and external signing interfaces. Its message randomizer must not be confused with the optional randomness supplied to signing. The pure and pre-hash interfaces also have defined encodings and context handling. Follow FIPS 205, Sections 4, 9, and 10 exactly when evaluating an implementation.

For an integration review, I would ask for:

• The precise algorithm identifier, profile, implementation version, and API contract.
• Known-answer and interoperability evidence, with the exact test configuration recorded.
• Negative tests for malformed signatures, wrong keys, altered messages, and context mismatches.
• A documented key lifecycle and update/recovery policy.
• Platform measurements for memory, latency, and failure behaviour.

A protocol decision also needs a clear validation rule. If a transition uses two signature schemes, explicitly define what the verifier must accept or reject; simply appending two signatures does not define a migration policy.

Correction and review note

This article previously used an incorrect algorithm spelling and included simplified pseudocode and a parameter-parsing example that should not be used to implement SLH-DSA. Those examples have been removed. The public URL is retained so existing links continue to work.

The old material also conflated the signing randomness input with the signature’s randomization string, understated the public-key length, and suggested arbitrary parameter choices. The revised guide points to the standard for those details and limits itself to architecture and integration questions.

Primary references

• NIST FIPS 205 publication record
• FIPS 205 full specification: Sections 3–4, 9–11, and Table 2.

From analysis to an engineering decision

Turn the questions in this article into a scoped architecture review, threat model, or migration plan.

Explore support for a cryptographic architecture or post-quantum migration challenge