Algorithms guide · updated 2 November 2026
ML-KEM, ML-DSA and SLH-DSA compared
NIST published three post-quantum standards in August 2024. ML-KEM (FIPS 203) sets up shared keys. ML-DSA (FIPS 204) signs things. SLH-DSA (FIPS 205) also signs things, with larger signatures and a different mathematical basis.
Which one does what
| Standard | Replaces | Based on | Was called |
|---|---|---|---|
| ML-KEM, FIPS 203 | RSA and elliptic-curve key exchange | Lattices | CRYSTALS-Kyber |
| ML-DSA, FIPS 204 | RSA, ECDSA and EdDSA signatures | Lattices | CRYSTALS-Dilithium |
| SLH-DSA, FIPS 205 | Signatures, as a backup | Hash functions | SPHINCS+ |
SLH-DSA exists because it does not depend on lattices. If a weakness were found in lattice schemes, a hash-based signature would be unaffected. NIST is also developing a standard from FALCON and one for HQC, an alternative to ML-KEM.
Sizes, measured
We generated each key and ran each operation with OpenSSL 3.6.3 rather than copy a table. Sizes are in bytes.
| Key establishment | Public key | Ciphertext |
|---|---|---|
| ML-KEM-512 | 800 | 768 |
| ML-KEM-768 | 1,184 | 1,088 |
| ML-KEM-1024 | 1,568 | 1,568 |
| Signatures | Public key | Signature |
|---|---|---|
| Ed25519 (for comparison) | 32 | 64 |
| RSA-2048 (for comparison) | 270 | 256 |
| ML-DSA-44 | 1,312 | 2,420 |
| ML-DSA-65 | 1,952 | 3,309 |
| ML-DSA-87 | 2,592 | 4,627 |
| SLH-DSA-SHA2-128s | 32 | 7,856 |
| SLH-DSA-SHA2-128f | 32 | 17,088 |
An ML-DSA-65 signature is about 52 times the size of an Ed25519 one. Size is where most of the engineering work in this migration goes. Protocols with tight limits on size, such as blockchains and constrained devices, feel it most. NIST warns that some protocols will need more than a new identifier because of these sizes.
Which to use
Key exchange: ML-KEM-768. TLS already deploys it in hybrid with X25519, as X25519MLKEM768. Hybrids are a safe first step, because the session stays secure if either part holds.
General signatures: ML-DSA. It is the balanced default.
Long-lived roots and firmware: consider SLH-DSA where signature size is acceptable and verification must stay trustworthy for decades.
What we run
functorfund.com negotiates X25519MLKEM768 in TLS 1.3. Quantum Core's release checksums are signed with ML-DSA-65, and Functor testnet accounts can add an ML-DSA-44 key. Our deployment script checks the first two live after every release.
To see what your own code still relies on, read what a CBOM is and the migration deadlines, or run Quantum Core on a repository.
Is ML-KEM the same as Kyber?
ML-KEM is the standardised form of CRYSTALS-Kyber. NIST made changes during standardisation, so the two do not interoperate as is.
Should I use SLH-DSA or ML-DSA?
ML-DSA is the usual default. SLH-DSA suits cases that accept large signatures in exchange for relying only on hash functions.
Does AES need replacing?
No. NIST says symmetric standards are less vulnerable, and it does not expect to need to transition away from them for this migration.