SLH-DSA signature sizes
SLH-DSA signatures range from 7,856 bytes (SLH-DSA-128s) to 49,856 bytes (SLH-DSA-256f). Public keys are tiny: 32, 48 or 64 bytes.
Even the smallest SLH-DSA signature is 123× an Ed25519 signature, and doesn't fit in a single cookie, QUIC datagram or 3-certificate TLS message.
Raw sizes (FIPS 205)
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, standardised from SPHINCS+) trades signature size for conservative security: it relies only on hash functions. The s ("small") sets have smaller signatures but sign slowly; the f ("fast") sets sign faster with much larger signatures. SHA2 and SHAKE variants of the same set have identical sizes.
| Parameter set | Security | Public key | Private key | Signature | Base64 signature | vs. Ed25519 sig |
|---|---|---|---|---|---|---|
| SLH-DSA-128s | NIST level 1 | 32 | 64 | 7,856 | 10,476 | 123× |
| SLH-DSA-128f | NIST level 1 | 32 | 64 | 17,088 | 22,784 | 267× |
| SLH-DSA-192s | NIST level 3 | 48 | 96 | 16,224 | 21,632 | 254× |
| SLH-DSA-192f | NIST level 3 | 48 | 96 | 35,664 | 47,552 | 557× |
| SLH-DSA-256s | NIST level 5 | 64 | 128 | 29,792 | 39,724 | 466× |
| SLH-DSA-256f | NIST level 5 | 64 | 128 | 49,856 | 66,476 | 779× |
What SLH-DSA breaks
| Limit | Carried as | SLH-DSA-128s | SLH-DSA-128f | SLH-DSA-192s | SLH-DSA-192f | SLH-DSA-256s | SLH-DSA-256f |
|---|---|---|---|---|---|---|---|
| QUIC datagram | 1,200 B, raw | +6,656 | +15,888 | +15,024 | +34,464 | +28,592 | +48,656 |
VARCHAR(255) | Base64 | +10,221 | +22,529 | +21,377 | +47,297 | +39,469 | +66,221 |
VARCHAR(1024) | Base64 | +9,452 | +21,760 | +20,608 | +46,528 | +38,700 | +65,452 |
| PostgreSQL B-tree index | 2,704 B, Base64 | +7,772 | +20,080 | +18,928 | +44,848 | +37,020 | +63,772 |
| Browser cookie | 4,096 B, as JWT | +6,659 | +18,968 | +17,816 | +43,736 | +35,907 | +62,659 |
| mbedTLS record buffer | 16,384 B, 3-cert chain | +8,059 | +35,755 | +33,211 | +91,531 | +73,963 | +134,155 |
Overflow in bytes. The TLS chain uses SLH-DSA for every certificate in a 3-certificate chain.
Where SLH-DSA fits
Its size rules it out of per-request paths (cookies, headers, datagrams) and makes it awkward in TLS chains. It's a strong fit where signatures are verified rarely and long-term trust matters most: firmware and software signing, root certificates, and archived documents. CNSA 2.0 favours stateful hash-based schemes (LMS, XMSS) or ML-DSA for software and firmware signing, so check which your compliance target requires.
Find every limit these sizes break in your stack
Paste a migration, an nginx.conf or an mbedTLS header into the checker, or ask us for a free scan of the whole repository.