ML-DSA & signatures
proving who you are after RSA breaks
Key facts
- FIPS 204ML-DSA, was Dilithium
- Main standard
- FIPS 205SLH-DSA, hash-based
- Backup
- FN-DSAFalcon, compact signatures
- Third option
- RSA, ECDSAfor signing
- Replaces
Encryption keeps secrets. Signatures prove who sent something, and they are the harder migration: the certificate in a car, a passport chip or a satellite may need to stay valid for twenty years.
Digital signatures are the quieter half of the post-quantum migration and in several respects the harder one. Encryption protects a conversation while it happens. A signature proves who something came from, and signatures have to keep being trusted for as long as the thing they signed is in service.
What they protect
Signatures underpin more of everyday computing than most people realise. The certificate that proves a website is who it claims to be. The signature on a software update that stops an attacker shipping malware to millions of devices. Passport chips, bank cards, the firmware in a car. All rest on RSA or elliptic-curve signatures, and Shor’s algorithm breaks both.
The standards
NIST published two signature standards alongside ML-KEM in August 2024, and a third, FN-DSA, based on the Falcon algorithm, is still working through the standardisation pipeline as FIPS 206.
ML-DSA (FIPS 204), previously CRYSTALS-Dilithium, is the primary recommendation. Like ML-KEM it is lattice-based, which means one family of mathematics underlies the main key exchange and the main signature scheme. It offers a good balance of signature size, speed and security margin.
SLH-DSA (FIPS 205), previously SPHINCS+, is the insurance policy. It is built entirely from hash functions, whose security is far better understood than lattices and which are not threatened by Shor’s algorithm. Its signatures are considerably larger and slower, so it is not the everyday choice, but if lattice cryptography were ever broken, SLH-DSA would stand on completely different foundations.
FN-DSA, previously Falcon, offers much more compact signatures for situations where bandwidth is tight, at the cost of implementation complexity that makes side-channel-resistant code harder to write.
Why signatures are the harder migration
Two reasons. First, longevity: a key exchange protects one session, so once you switch, past sessions are not retroactively exposed by a future break of the old algorithm. A signature is different, because a certificate issued today may need to be trusted for years, which means the migration deadline is effectively the deadline minus the lifetime of the things you sign.
Second, size. ML-DSA signatures are several kilobytes where an elliptic-curve signature is 64 bytes. That is fine for a web certificate and genuinely difficult for a constrained device, a satellite link, or a protocol whose packet sizes were fixed decades ago.
Where it stands
ML-DSA and SLH-DSA are final standards and implementations are widely available. Deployment lags behind ML-KEM, partly because key exchange could be upgraded invisibly inside browsers while signatures require certificate authorities, device manufacturers and standards bodies to move together. The devices being manufactured now, with twenty-year service lives, are the ones where the decision cannot be deferred.