Short answer: ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are the two post-quantum digital signature standards NIST published on 13 August 2024. ML-DSA is lattice-based; SLH-DSA is hash-based and rests on a more conservative assumption but produces larger signatures.
Digital signatures prove who sent something and that it was not changed. They sit behind software updates, website certificates, signed documents, firmware and identity systems. RSA and elliptic curve signatures are expected to fall to a large quantum computer, so they need replacing.
Two standards, two approaches
NIST has standardised two post-quantum signature schemes, both published on 13 August 2024.
FIPS 204 defines ML-DSA, the Module-Lattice-Based Digital Signature Algorithm. It is derived from CRYSTALS-Dilithium and relies on lattice problems, the same family of mathematics behind ML-KEM for key exchange.
FIPS 205 defines SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm. It is derived from SPHINCS+ and relies only on the security of hash functions.
How they differ
The difference that matters most is the security assumption. ML-DSA depends on lattice problems. These have resisted years of public analysis but are a newer foundation than hash functions. SLH-DSA depends on hash functions, a far older and better-understood building block. The trade-off is practical: hash-based signatures are generally larger and slower than lattice-based ones.
"Stateless" is worth explaining. Some earlier hash-based schemes required the signer to track state, such as which one-time keys had been used, and reusing a key broke the security. A stateless scheme removes that operational hazard, which makes it much easier to deploy safely.
Having both in the standard set is deliberate. If a weakness were ever found in lattice problems, a signature scheme built on a different foundation is already standardised and ready.
Where signatures are used
- Software and firmware updates.
- Website and internal certificates.
- Code signing and package repositories.
- Signed documents and contracts.
- Device and identity attestation.
- Blockchain and wallet transactions, though many networks use their own signature schemes and need their own migration.
Which signatures to migrate first
Not all signatures are equally urgent. A signature only has to be secure at the moment someone checks it, so a short-lived one is less exposed than a long-lived one. The priority is signatures that must stay trustworthy for years:
- Firmware and boot roots in devices that will run for a decade or more.
- Root certificates and long-lived signing keys.
- Archived signed records that need to be verifiable far into the future.
What to do
Inventory where you sign and verify. Ask suppliers about support for ML-DSA and SLH-DSA, and about their plans for certificates and code-signing chains. Make sure devices you ship or buy today can receive updated verification keys later.
Performance and size in practice
Signature size and verification speed matter more than they sound. A certificate chain carries several signatures and public keys, and larger post-quantum ones add up. That affects handshake size, storage on small devices and bandwidth on constrained links. Hash-based signatures are generally the largest, which is one reason they tend to suit infrequent, high-value signing such as firmware roots better than every web connection. Test on your own hardware before you commit, and ask vendors for real figures rather than general claims.
A note on hybrid signatures
As with key exchange, some deployments will combine a classical signature with a post-quantum one during the transition, so a verifier can accept either. This adds size but lowers risk while confidence in the new schemes builds. Whether hybrid signatures make sense for you depends on the system, so raise it with your suppliers early.
Why this matters for Ireland
Ireland's strength in pharma, medical devices, software and data infrastructure means many Irish companies ship or depend on signed firmware and software. Planning the signature migration early protects both their own products and their customers.
This piece is written from Clonmel, Tipperary for Quantum Ireland. It reflects our own views, not a government position.
FAQ
What is the difference between ML-DSA and SLH-DSA?
ML-DSA relies on lattice problems. SLH-DSA relies only on the security of hash functions. Hash-based signatures are generally larger and slower.
What does "stateless" mean in SLH-DSA?
The signer does not have to track which one-time keys were used. Earlier hash-based schemes needed that, and reusing a key broke the security, so stateless schemes are safer to deploy.
Why did NIST standardise two signature schemes?
Two schemes built on different mathematical foundations give a fallback if one family is ever weakened.
Which signatures should be migrated first?
Long-lived ones: firmware and boot roots in devices that will run for many years, root certificates and long-lived signing keys, and archived records that must stay verifiable.
Are these signatures used in blockchains?
Many networks use their own signature schemes and need their own migration. NIST's standards do not change them automatically.
All field notes