SLH-DSA and FN-DSA

Mental model

In M2 you saw that hash-based signatures (stateful LMS/XMSS and stateless SLH-DSA) rest on a different trust model (hash function preimage resistance). In this lesson we make the general-purpose, stateless member of that family, SLH-DSA, concrete with FIPS 205’s own size table, and get to know the third lattice-based signature family, FN-DSA (Falcon), with its real (pre-draft) status today.

SLH-DSA: ‘s’ or ‘f’, a real trade-off

FIPS 205 defines 12 parameter sets; each is a hash family (SHA2/SHAKE), a security parameter, and a choice of ‘s’ (small signature) or ‘f’ (fast signing). Even within the same category the choice makes a big difference: SLH-DSA-SHA2-128s has a public key of 32 B^SOURCED and a signature of 7856 B^SOURCED, while SLH-DSA-SHA2-128f in the same category (category 1) has a signature of 17088 B^SOURCED, more than twice as large. What you get for that price is faster signing; the ‘s’ variant does more computation while signing to keep the signature small, and the ‘f’ variant does the opposite. The same pattern repeats in the other two categories: 192s pk 48 B^SOURCED/sig 16224 B^SOURCED (category 3^SOURCED), 256s pk 64 B^SOURCED/sig 29792 B^SOURCED (category 5^SOURCED).

Remember XMSS’s hard ceiling of 2^20 signatures from M2: once the OTS keys ran out, a new key was needed. Because SLH-DSA is stateless it does not carry that limit; FIPS 205’s own footnote makes this concrete: the parameter sets were designed for up to 2^64^SOURCED signatures, and “even if you signed 10 billion times per second, using up this number would take more than 58 years.” That is the concrete counterpart of the state discussion in M2: the price of choosing SLH-DSA is size (larger signatures than LMS/XMSS), and the gain is that the state management risk disappears entirely.

FN-DSA: the smallest signature, but not even a draft yet

The third signature family, FN-DSA, is based on the Falcon algorithm NIST selected and will be defined in FIPS 206. The summary of NIST’s own 2025 status presentation (Ray Perlner, Computer Security Division) is clear: “FN-DSA has very small signatures and public keys but is difficult to implement… significantly smaller than ML-DSA (FIPS 204)… Operations in KeyGen and Signing need floating-point arithmetic. This can lead to challenges for validation and side-channel protection.” So the price of FN-DSA’s small size is that signing requires floating-point arithmetic, which makes writing a constant-time, side-channel-safe implementation a much harder engineering problem than for ML-DSA or SLH-DSA. NIST’s own presentation devotes a long section to this difficulty (floating point, validation, side channels) and mentions a consultation process with the Falcon team lasting “a few years”. It is a reasonable inference that this difficulty contributed to FIPS 206 arriving much later than the other three FIPS (203/204/205), but the presentation does not state it explicitly as the single, direct cause.

Status, live-verified: the same presentation says “We expect to release an Initial Public Draft soon… It’s basically written, awaiting approval” (2025). If you check directly today (September 2026) (csrc.nist.gov/pubs/fips/206/ipd), the address still returns 404, so the IPD has not been published. FN-DSA is SELECTED2022-07-05 with not even a draft. The figures in falcon-sign.info’s own original specification (Falcon-512 pk 897 B^SOURCED/sig 666 B^SOURCED, Falcon-1024 pk 1793 B^SOURCED/sig 1280 B^SOURCED) are the only concrete reference available today, but they are not FIPS 206’s own text. When someone tells an architect “we support FN-DSA”, the question to ask is “against which specification, given that FIPS 206 does not exist yet?”