SLH-DSA changes signature size budgets before it changes the signature model

SLH-DSA, a stateless hash-based signature scheme, is governed by FIPS 205. This system eliminates the need to track a signing counter across operations, simplifying backup, replication, and failover processes. However, this comes at the cost of increased bytes and CPU work for each signature. FIPS 205 supports twelve parameter sets, with six instantiated using SHA-2 or SHAKE, differentiating between a small-signature variant and a fast-signing variant.

When comparing security levels, teams must be aware of this distinction to ensure their deployment aligns with their specific needs. The smallest signature sizes, as per NIST SP 800-230, are 7,856 bytes at security level 1, 16,224 bytes at level 3, and 29,792 bytes at level 5. These values do not include additional components such as certificates, envelopes, log entries, or API framing.

For systems with strict limits, like a 4 KB request cap, transitioning to the smallest signature size may require adjusting the transport contract. System administrators should verify every instance where a signature is stored, including release manifests, package metadata, audit logs, API payloads, configuration bundles, and long-lived archives.

This includes examining database columns, message limits, compression assumptions, and base64 overhead. While a signature may pass in a unit test, it can still fail in a production environment with size constraints. It is crucial to assign separate keys for different trust domains, such as product, environment, and signing policy.

Every signature must include the parameter set and key identifier to prevent verifiers from incorrectly inferring the algorithm used by the signer. Despite being stateless, SLH-DSA still requires a secure private key. An attacker gaining access to this key can sign messages indefinitely, so proper management of this key is essential.

SLH-DSA verification, although cheaper than signing, can still be resource-intensive when dealing with a high volume of signatures. System developers should implement bounded sizes and time budgets around untrusted input and reject unknown parameter sets before allocating buffers. A comprehensive migration test should be conducted, signing representative artifacts with each approved parameter set and measuring the full encoded size while running every consumer in the path, including the oldest supported client, release mirror, logging pipeline, and recovery procedure.

If an SLH-DSA migration is not feasible, clearly identify the limiting component instead of using a generic "algorithm not supported" error message.