In August 2024, NIST finalised the first three post-quantum cryptography standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). This guide is the algorithm-level companion to our crypto agility track, with the parameter sets, key and signature sizes, and OpenSSL syntax that practitioners actually need.
On 13 August 2024 NIST published the first three post-quantum cryptography standards: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) for hash-based signatures. A fourth standard, FIPS 206 (FN-DSA, based on Falcon), is still in draft, and HQC was selected in March 2025 as a code-based KEM to diversify the lattice-only signature path. Together they form the algorithm bench that will replace RSA and elliptic-curve cryptography in TLS, S/MIME, code signing, and the rest of the WebPKI over the next decade.
The mapping to legacy algorithms is straightforward. ML-KEM replaces RSA and ECDH key establishment, ML-DSA replaces RSA and ECDSA signatures, and SLH-DSA is a deliberately conservative hash-based backstop for long-lived signatures where the security assumptions of lattice schemes feel too young. Each algorithm comes in three parameter sets targeting NIST security categories 1, 3, and 5 — roughly equivalent to AES-128, AES-192, and AES-256 against a quantum attacker.
This guide is the algorithm deep-dive companion to crypto agility and post-quantum. It assumes familiarity with public-key cryptography and is meant for architects, PKI engineers, and security leads who need to know what ML-KEM-768 actually is, how big an ML-DSA signature is on the wire, and when SLH-DSA earns its much heavier cost. Migration strategy, discovery, and inventory belong to the parent guide; here we stay close to the standards, the numbers, and the tooling.
The NIST Post-Quantum Cryptography project opened in 2016, ran through three competitive rounds, and in July 2022 announced the first selection: Kyber for key encapsulation, Dilithium and Falcon for general-purpose signatures, SPHINCS+ as a hash-based alternative. Two years of standardisation followed, and the renamed schemes were published as final FIPS standards on 13 August 2024. Falcon, renamed FN-DSA, is still draft FIPS 206 because its floating-point signing is hard to make constant-time safely. A fourth round picked HQC in March 2025 as a code-based KEM, hedging against an unforeseen break in the lattice family that already dominates the lineup.
The threat model has not changed. A cryptographically relevant quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography in polynomial time, retiring overnight the two algorithm families that underpin almost every TLS handshake, S/MIME signature, and code signing certificate in use today. No public estimate puts that machine within the next few years, but it does not have to exist yet to matter. Harvest-now, decrypt-later is already a viable strategy for any adversary with the storage budget to keep encrypted traffic until the hardware catches up — and anything signed today with a long validity window has to survive that future too.
What changes with PQC is which mathematical structures the cryptography relies on. Lattice schemes (ML-KEM, ML-DSA) draw their security from Learning With Errors and Module-LWE. Hash-based signatures (SLH-DSA) rely only on the collision and second-preimage resistance of standard hash functions — a much older, much more conservative assumption, at the cost of dramatically larger signatures.
The naming convention is worth memorising. ML-KEM and ML-DSA are the two module-lattice families, both designed by the team behind CRYSTALS-Kyber and CRYSTALS-Dilithium. SLH-DSA is stateless hash-based, which matters because earlier hash-based schemes (XMSS and LMS, standardised in RFC 8391 and RFC 8554) require the signer to track which one-time key has already been used; losing that state breaks security. SLH-DSA dispenses with the bookkeeping at the cost of larger signatures.
Module-Lattice-Based Key-Encapsulation Mechanism. Replaces RSA and ECDH wherever two parties need to agree on a shared symmetric key. Three parameter sets: ML-KEM-512 (security category 1, ~AES-128), ML-KEM-768 (category 3, ~AES-192), ML-KEM-1024 (category 5, ~AES-256). Public keys range from 800 B to 1568 B; ciphertexts from 768 B to 1568 B. Fast on commodity CPUs and friendly to constant-time implementation, which is why every browser vendor reached for it first.
Module-Lattice-Based Digital Signature Algorithm. The default replacement for RSA and ECDSA signatures in certificates and protocols. Three parameter sets: ML-DSA-44 (security category 2), ML-DSA-65 (category 3), ML-DSA-87 (category 5). Public keys range from 1312 B to 2592 B; signatures from 2420 B to 4627 B. Signing and verification are an order of magnitude slower than ECDSA but still well within practical budgets for almost every workload.
Stateless Hash-Based Digital Signature Algorithm. A deliberately conservative alternative whose security relies only on the hash function. Twelve parameter sets across two families (SHA2 and SHAKE) and two profiles per security level: -s (small) variants minimise signature size at the cost of slower signing, -f (fast) variants do the opposite. Signatures range from roughly 7.8 KB (SLH-DSA-128s) to over 49 KB (SLH-DSA-256f). SLH-DSA earns its place where lattice assumptions feel too young: long-lived root CAs, firmware, archival signatures.
FN-DSA (Falcon, draft FIPS 206) is the smaller-signature lattice signature scheme — about 666 B at category 1 — but its reference implementation uses floating-point arithmetic that is hard to make constant-time across the diversity of hardware that signs certificates. HQC was selected in round 4 (March 2025) as a code-based KEM intended to diversify the lineup, so that a single mathematical break would not retire the entire PQ stack.
The standard PQ key agreement primitive. In TLS 1.3 it is now deployed as X25519MLKEM768, a hybrid key share that runs classical X25519 and ML-KEM-768 in parallel and combines their outputs into the handshake secret (the IETF TLS WG draft `draft-ietf-tls-ecdhe-mlkem` defines the named group; RFC 9794 covers the hybrid terminology). Chrome and Edge enable it by default for most users; Cloudflare and other large CDNs accept it server-side. This is the only PQ primitive most operators will see live traffic from in 2026.
The default signature replacement for certificates, S/MIME, code signing, JWTs, and the long tail of "anything currently using RSA or ECDSA". The LAMPS working group is actively profiling its use in X.509 (draft-ietf-lamps-dilithium-certificates), and Cloudflare, Microsoft, and Google have all published experimental ML-DSA certificate issuance from internal CAs.
The right tool when the signature must remain verifiable for decades on assumptions that do not depend on the lattice problems holding up. Typical homes: root CA self-signatures, firmware images for hardware shipped with 20-year support windows, notarisation of immutable records. SLH-DSA's signature sizes make it unsuitable for high-volume TLS or per-request signing, but irrelevant for sign-once-verify-many use cases.
For the next several years the realistic deployment is hybrid: a classical key exchange or signature alongside a PQ one, both verified, with the connection only succeeding when both pass. The hybrid surface is where TLS 1.3 already sits (X25519MLKEM768), where LAMPS is heading for X.509 (draft-ietf-lamps-pq-composite-sigs), and where regulators such as ANSSI explicitly recommend new deployments start.
The biggest practical difference between the new algorithms and the old is wire size. RSA-3072 and ECDSA P-256 keys and signatures sit in the hundreds of bytes; the lattice schemes are an order of magnitude larger, and SLH-DSA two orders. Capacity planning at the edge — TLS record sizes, CT log entries, certificate bundles in container images — has to account for this.
ML-DSA-65 signatures are roughly 50 times an ECDSA P-256 signature and about nine times an RSA-3072 one, which means every TLS handshake using ML-DSA pushes several extra kilobytes per certificate, and a full certificate chain with three or four ML-DSA-signed certificates adds tens of kilobytes. SLH-DSA-128s is roughly 120× an ECDSA P-256 signature; SLH-DSA-128f, more than 260×. The "s" suffix optimises for size and pays in signing time; "f" optimises for signing speed and pays in size. For a one-time root signature you want "s"; for anything signing more than occasionally, "f".
Speed is more reassuring. ML-KEM-768 encapsulation and decapsulation are both faster than X25519 on most modern hardware, and ML-DSA-65 verification is competitive with RSA-3072 verification. SLH-DSA signing is genuinely slow — tens to hundreds of milliseconds on commodity CPUs — but its verification is fast, which is what matters for sign-once-verify-many workloads.
| Algorithm | Public key | Signature / ciphertext | Speed class | Hardware-friendly |
|---|---|---|---|---|
| RSA-3072 | 384 B | 384 B | Slow signing, fast verify | Mature, ubiquitous HSM support |
| ECDSA P-256 | 64 B | 64 B | Fast both ways | Mature, ubiquitous HSM support |
| ML-KEM-768 | 1184 B | 1088 B (ciphertext) | Very fast both ways | Constant-time friendly, software-only at first |
| ML-DSA-65 | 1952 B | 3293 B | Fast verify, slower sign | Limited HSM support in 2026 |
| SLH-DSA-128s | 32 B | ~7856 B | Very slow signing | Hash-only, friendly to existing hash accelerators |
| SLH-DSA-128f | 32 B | ~17088 B | Faster signing, larger sig | Hash-only, friendly to existing hash accelerators |
OpenSSL 3.5 (April 2025) is the first upstream release that ships ML-KEM, ML-DSA, and SLH-DSA in the default provider, so the commands below assume a modern build. On older systems the same algorithms are available via the OQS provider loaded against OpenSSL 3.x; the algorithm strings are the same but the configuration is not, so always check `openssl list -providers -kem-algorithms` and `openssl list -signature-algorithms` against the binary you actually run.
The `-text -noout` flags print the parsed key, useful for confirming the algorithm OID matches what the certificate consumer expects. If the output shows raw bytes only, your build predates ML-DSA's text-printing support — fall back to `openssl asn1parse` to inspect the SubjectPublicKeyInfo.
# Confirm the provider really exposes ML-DSA / ML-KEM / SLH-DSA on this build
openssl list -providers
openssl list -signature-algorithms | grep -Ei 'ML-DSA|SLH-DSA'
openssl list -kem-algorithms | grep -i ML-KEM
# Generate an ML-DSA-65 key pair (FIPS 204, security category 3)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
# Inspect the public half — note the algorithm OID and the much larger key
openssl pkey -in mldsa65.key -pubout -text -nooutThe signing surface is intentionally the same as for any other key algorithm in OpenSSL: `pkeyutl` with `-sign` and `-verify`, the algorithm comes from the key. The block below generates an SLH-DSA-128s key alongside ML-DSA-65 so the on-disk signature sizes can be compared directly with `ls -l`.
The exact algorithm string for SLH-DSA depends on the provider — FIPS 205 defines parameter sets by hash family (SHA2 vs SHAKE) and profile (s vs f), and not every implementation exposes the same names. If `SLH-DSA-SHA2-128s` is rejected, try `SLH-DSA-128s`, `slh-dsa-sha2-128s`, or whatever appears in `openssl list -signature-algorithms` (syntax depends on provider — check `openssl list -providers -kem-algorithms` for the corresponding KEM names).
# Round-trip with ML-DSA-65
echo "post-quantum payload" > msg.bin
openssl pkeyutl -sign -inkey mldsa65.key -rawin -in msg.bin -out msg.mldsa65.sig
openssl pkeyutl -verify -inkey mldsa65.key -rawin -in msg.bin -sigfile msg.mldsa65.sig
# -> Signature Verified Successfully
# Same round-trip with SLH-DSA-128s (FIPS 205, "small" profile)
openssl genpkey -algorithm SLH-DSA-SHA2-128s -out slhdsa128s.key
openssl pkeyutl -sign -inkey slhdsa128s.key -rawin -in msg.bin -out msg.slhdsa128s.sig
openssl pkeyutl -verify -inkey slhdsa128s.key -rawin -in msg.bin -sigfile msg.slhdsa128s.sig
# Compare on-disk sizes — the SLH-DSA signature is ~7.8 KB vs ~3.3 KB for ML-DSA
ls -l msg.mldsa65.sig msg.slhdsa128s.sigThe decision is almost always made for you by context: protocol, key lifetime, regulatory posture. The five rules below cover the cases that show up in practice.
For any new TLS, IPsec, SSH, or QUIC deployment in 2026 the right key-exchange choice is the hybrid X25519MLKEM768 named group used in TLS 1.3 — the IETF TLS WG draft `draft-ietf-tls-ecdhe-mlkem` defines the named group; RFC 9794 covers the hybrid terminology — and is already shipping in Chrome and Edge. The hybrid construction is at least as secure as classical X25519 even if ML-KEM is later broken, for the cost of an extra ~1.1 KB in the ClientHello. This is the cheapest PQ control you can deploy and it directly defeats harvest-now-decrypt-later for new sessions.
Anywhere you would have reached for RSA or ECDSA — certificate signing, JWT issuance, code signing, S/MIME, document signing — ML-DSA is the default PQ replacement. Plan for 50× to 100× the signature size of ECDSA. That cost is bearable for every workload except the most bandwidth-sensitive (CT log entries, header-sized signatures in constrained protocols), but it has to be planned for. The LAMPS working group's X.509 profile (draft-ietf-lamps-dilithium-certificates) is the document to track if you operate your own PKI.
If a signature must remain verifiable for 20+ years, or if policy explicitly requires non-lattice cryptography, SLH-DSA is the answer. Natural homes: root CA self-signatures, secure-boot anchors, firmware update keys, notarised archival records. Pick the -s parameter set for one-time signatures; pick -f if the signing rate exceeds a few per minute. SLH-DSA is also the choice when you need a PQ signature your HSM can already accelerate — every byte of an SLH-DSA signature is the output of a standard hash function.
For the next 3–7 years the realistic deployment is hybrid: classical + PQ in parallel, both verified, the connection or signature only valid when both pass. That is the model already deployed in TLS 1.3 with X25519MLKEM768, and the one LAMPS is profiling for X.509 in draft-ietf-lamps-pq-composite-sigs. Hybrid protects against an early break in either family, at the cost of roughly double the bandwidth and verification time. Once confidence matures and the classical algorithms are formally deprecated the wrappers come off — but plan for the transition itself to take most of the decade.
The most common failure mode of PQ migrations is starting with the algorithm and not the asset list. Before any cutover, run a full certificate discovery and inventory: every certificate, every embedded key, every JWT-signing service, every code signing chain. Then prioritise by exposure (anything signed for >5 years, anything decrypting harvested traffic) and migrate in the order discover → prioritise → hybrid → cutover. Strategy and governance live in the crypto agility and post-quantum guide; this one stays on the algorithms.
Discovery-first PQC readiness via /audit-pqc — the free Evertrust PQC audit walks your estate and produces a prioritised list of certificates and signing services exposed to harvest-now-decrypt-later and to long-validity quantum risk. It is the right first step before any algorithm choice, and the report is structured so it feeds directly into a migration plan against the standards described in this guide.
Algorithm-agnostic issuance and renewal — Evertrust PKI and CLM are designed around the algorithm, not bolted to a single one. The same enrollment, approval, and renewal workflows you run today for RSA and ECDSA certificates will run unchanged for ML-DSA, SLH-DSA, and hybrid certificates as the relevant CA profiles stabilise. You change a policy, not a platform.
Hybrid certificate paths during the transition — for the multi-year period when both classical and PQ signatures need to be valid in parallel, Evertrust tracks the LAMPS WG hybrid composite signature profiles as they stabilise, so the cut-over from hybrid to pure-PQ is a policy change rather than a re-implementation. One inventory, one policy engine, one place to prove to auditors that the migration is on track.