Post-quantum signatures: ML-DSA, SLH-DSA, and FN-DSA compared

Digital signatures authenticate certificates, code, firmware, documents, and tokens. Unlike key exchange, signatures are not exposed to harvest-now-decrypt-later — you cannot forge a signature retroactively, because a forgery is only useful once the quantum computer already exists. That makes signature migration important but generally second in priority to key establishment.

FIPS 204 — ML-DSA (the default)

FIPS 204 standardizes ML-DSA, derived from CRYSTALS-Dilithium, as the general-purpose replacement for RSA and ECDSA signatures. It is lattice-based, fast to sign and verify, with moderate key and signature sizes. Parameter sets ML-DSA-44, 65, and 87 target increasing security categories. For most certificate, token, and code-signing use, ML-DSA is the working default.

FIPS 205 — SLH-DSA (the conservative option)

FIPS 205 standardizes SLH-DSA, derived from SPHINCS+. Its security depends only on the underlying hash function, not on lattice assumptions, so it gives the strongest confidence against a future cryptanalytic surprise. The trade-off is size and speed: signatures can be tens of kilobytes and signing is comparatively slow. It is stateless, which avoids the operational danger of stateful hash-based schemes. Reach for SLH-DSA on long-lived, high-assurance signing such as firmware and roots of trust.

FN-DSA — the compact one, still in draft

FN-DSA, based on FALCON, produces significantly smaller signatures than ML-DSA, which is attractive where bandwidth or storage is tight (for instance large certificate chains). Its drawback is that secure implementation requires constant-time floating-point Gaussian sampling, which is easy to get wrong. NIST has signalled it as a future standard; do not deploy it in production until the FIPS is final and vetted implementations exist.