Post-Quantum Digital Signatures: ML-DSA and SLH-DSA Compared

Key exchange protects secrecy. Digital signatures protect authenticity: proof that a certificate, software update or document came from the claimed party and was not altered. A quantum computer running Shor's algorithm would let an attacker forge RSA and ECDSA signatures. NIST has standardized two post-quantum signature schemes, with a third (FN-DSA, based on Falcon) in the standardization pipeline.

ML-DSA (FIPS 204)

ML-DSA, derived from CRYSTALS-Dilithium, is the general-purpose choice. It is lattice-based like ML-KEM, which makes it fast and reasonably compact for a post-quantum signature.

For comparison, an ECDSA P-256 signature is about 64 bytes and an RSA-2048 signature is 256 bytes. The difference is the main engineering challenge.

SLH-DSA (FIPS 205)

SLH-DSA, derived from SPHINCS+, is built entirely from hash functions. Its security rests on the hash function's properties rather than on lattice problems, which is why it is considered the conservative backup: if lattice cryptography were ever weakened, SLH-DSA would be unaffected.

The trade-off is size and speed. Public keys are tiny (32 to 64 bytes), but signatures are large (for example about 7.8 KB for the smallest "s" variant at 128-bit security, rising to roughly 50 KB for the fastest high-security variants), and signing is slower than ML-DSA. It is stateless, so unlike older hash-based schemes it does not require tracking used one-time keys.

Which to use

Why signatures migrate later than key exchange

An attacker cannot go back and forge a signature on a session that already happened, so there is no equivalent of harvest-now-decrypt-later for authentication (see Harvest Now, Decrypt Later). The risk begins once a capable quantum computer exists. However, some signatures last a very long time: firmware roots of trust in devices that live 15 years, root CA certificates, and archived signed documents. Those need post-quantum signatures before the threat is real, because they cannot be easily replaced in the field.

Engineering impacts

Size. A certificate chain with three ML-DSA-65 signatures and public keys adds roughly 10 KB to a TLS handshake. That affects latency on slow links and may exceed limits in protocols designed around small signatures.

Ecosystem readiness. Certificate authorities, browser trust stores, HSMs and code-signing services each need to support the new algorithms. Public web PKI support is still maturing, so internal PKI and private code signing typically move first.

Hybrid and composite signatures. Some designs attach both a classical and a post-quantum signature so that verifiers pick whichever they support. Standards for composite certificates are still being developed.

Library support. OpenSSL 3.5 and later and several other libraries implement ML-DSA and SLH-DSA. Check your HSM and cloud KMS vendors separately, because hardware support often lags.

Planning checklist

1. Inventory every signing use: TLS certificates, code signing, container images, firmware, JWTs, S/MIME, documents (see Building a Cryptographic Inventory).
2. Mark long-lived signatures and roots of trust for early attention.
3. Check column, header and storage limits against the new sizes.
4. Ask CA, HSM and signing-service vendors for dated support commitments.
5. Build in agility so that algorithm choice is a policy (crypto-agility patterns).