SLH-DSA Signature Sizes: What Teams Need to Know

DEV Community

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

SLH-DSA changes signature size budgets before it changes the signature model SLH-DSA is a stateless hash-based signature scheme standardized in FIPS 205. It removes the need to track a signing counter between operations, which makes backup, replication, and failover easier than with stateful hash-based signatures. The tradeoff appears in the bytes and CPU work attached to each signature, not in the basic promise that a signature authenticates a message. FIPS 205 approves twelve parameter sets. Six parameter combinations are instantiated with SHA-2 or SHAKE. The names also distinguish a small-signature variant from a fast-signing variant. Teams that compare only the security level will miss this difference. A small deployment may need the fast variant to keep a signing service within its latency budget. A bandwidth-limited update channel may need the small variant even when its signing path is slower. Size is part of the protocol NIST SP 800-230 records the smallest signature sizes in the base standard as 7,856 bytes at security level 1, 16,224 bytes at level 3, and 29,792 bytes at level 5. Those values exclude the surrounding certificate, envelope, log entry, or API framing. A system with a fixed 4 KB request limit cannot move to the smallest of these signatures without changing its transport contract. Find every place where a signature is stored: release manifests, package metadata, audit logs, API payloads, configuration bundles, and long-lived archives. Check database columns, message limits, compression assumptions, and base64 overhead. A signature that passes in a unit test can still fail at a proxy with a smaller body limit. The signing capacity stated for the full design is large, but capacity is not a reason to share one private key across unrelated trust domains. Separate keys by product, environment, and signing policy. Record the parameter set and key identifier with every signature so a verifier does not infer the wrong algorithm from the signer's name. Stateless does not mean policy-free A stateless signer does not need a monotonically increasing counter, but it still needs a protected private key. An attacker who obtains the key can sign for as long as the verifier accepts it. Rotation, revocation, approval, and audit records remain deployment controls. Verification also has a resource budget. Hash-based verification is generally cheaper than signing, but a service that verifies large numbers of signatures can still exhaust CPU or memory. Put bounded sizes and time budgets around untrusted input. Reject unknown parameter sets before allocating buffers. Prepare a migration test that signs a representative artifact with each approved parameter set, measures the full encoded size, and runs every consumer in the path. Include the oldest supported client, the release mirror, the logging pipeline, and the recovery procedure. Where an SLH-DSA migration does not fit, state the limiting component rather than hiding it behind an "algorithm not supported" error. References NIST FIPS 205, Stateless Hash-Based Digital Signature Standard NIST SP 800-230 initial public draft, Additional SLH-DSA Parameter Sets for Limited-Signature Use Cases

Powered by Readybot.io