Nist Post Quantum Algorithms

The NIST post-quantum algorithms explained

NIST has standardised three post-quantum algorithms: ML-KEM for key establishment under FIPS 203, ML-DSA for general-purpose signatures under FIPS 204, and SLH-DSA for signatures requiring conservative assumptions under FIPS 205. LMS and XMSS are separately approved for firmware signing, and HQC is in preparation as a backup key encapsulation mechanism.

What are the NIST PQC algorithms?

The three primary standards were published on 13 August 2024, following an eight-year public evaluation process that began in 2016 and attracted 82 candidate submissions.

Each algorithm was renamed on standardisation, which causes persistent confusion in vendor documentation. CRYSTALS-Kyber became ML-KEM, CRYSTALS-Dilithium became ML-DSA, and SPHINCS+ became SLH-DSA. The renaming is not cosmetic. The standardised versions differ from the submissions in specific parameter and encoding choices, so a product advertising Kyber support is not necessarily FIPS 203 compliant.

The algorithms divide by function. ML-KEM performs key establishment and replaces RSA key transport and Diffie-Hellman. ML-DSA and SLH-DSA produce digital signatures and replace RSA and ECDSA. No post-quantum replacement is required for symmetric encryption, where AES-256 remains appropriate.

ML-KEM, FIPS 203: key establishment

ML-KEM is a module-lattice based key encapsulation mechanism. Rather than encrypting a key chosen by the sender, as RSA key transport does, it generates a shared secret and an encapsulation of it, which the recipient decapsulates using the private key. The output is a 32-byte shared secret used to key symmetric encryption.

ML-KEM-768 is the general default and is what most browser and platform deployments have adopted. Computationally it is fast, often faster than the elliptic curve exchange it replaces. The cost is size: an X25519 public key is 32 bytes against 1,184 for ML-KEM-768, which is a material increase in handshake volume although one that fits comfortably within normal packet sizes.

Key establishment was the first area to see broad deployment because it addresses harvest now, decrypt later exposure, and because a key exchange upgrade does not require any change to the certificate ecosystem.

ML-DSA, FIPS 204: general-purpose signatures

ML-DSA is a module-lattice based signature scheme and is the default replacement for RSA and ECDSA signatures in certificates, tokens and general software signing.

ML-DSA-65 is the common default; ML-DSA-87 is required under the US CNSA 2.0 suite for national security systems. Signing and verification are fast. The difficulty is size, and it compounds through a certificate chain: a chain carrying three ML-DSA signatures and three ML-DSA public keys is roughly an order of magnitude larger than its ECDSA equivalent, which is the principal obstacle to post-quantum authentication on the public web.

SLH-DSA, FIPS 205: conservative hash-based signatures

SLH-DSA is a stateless hash-based signature scheme. Its security rests only on the properties of the underlying hash function, which are far better understood than lattice assumptions. That makes it the conservative choice where the consequences of a future cryptanalytic result would be unacceptable.

The standard defines twelve parameter sets, combining SHA-2 or SHAKE, three security levels, and a choice between small signatures with slow signing, designated s, and fast signing with larger signatures, designated f. Public keys are very small at 32 to 64 bytes. Signatures are not: SLH-DSA-128s produces a 7,856 byte signature, and SLH-DSA-256s produces 29,792 bytes.

The practical positioning is narrow but important. SLH-DSA suits root certificate authorities, long-lived trust anchors and signing operations performed rarely, where a large signature is acceptable and slow signing is irrelevant. It is unsuitable for high-volume signing or size-constrained protocols.

LMS and XMSS, SP 800-208: stateful signatures for firmware

LMS and XMSS are stateful hash-based signature schemes, approved by NIST in SP 800-208 in 2020, several years before the main standards. They are supported in hardware security modules and secure elements today, which is why they are frequently the correct choice for firmware and secure boot verification.

The constraint is the state. Each private key may sign a strictly limited number of messages, and each signature must use a different one-time key. Reusing state destroys the security of the scheme entirely, so the signing infrastructure must guarantee that state is never duplicated, including across backups, failover and disaster recovery. That requirement rules the schemes out for general use and makes them appropriate only in controlled, centralised signing environments.

HQC and FN-DSA: the algorithms still to come

NIST selected HQC in March 2025 as a backup key encapsulation mechanism. It is code-based rather than lattice-based, so a cryptanalytic advance against structured lattices would not affect it. Its keys and ciphertexts are considerably larger than ML-KEM's and it is slower, so it is intended as insurance rather than as a default. The draft standard is in preparation, with final publication expected after that.

FN-DSA, formerly FALCON, is intended for publication as FIPS 206. It produces much smaller signatures than ML-DSA, which makes it attractive for certificate chains and constrained protocols, but it depends on floating-point arithmetic that is difficult to implement in constant time without side-channel exposure. Planning should not assume its availability.

How the NIST PQC algorithms compare

For comparison, an ECDSA P-256 public key is 64 bytes with a 64-byte signature, and an X25519 public key is 32 bytes. Every post-quantum option is between one and three orders of magnitude larger.

Which NIST PQC algorithm to use for each purpose

Practical deployment considerations

The recurring lesson from deployment is that the algorithms work and the surrounding infrastructure does not. Failures encountered in test environments are almost never cryptographic. They are certificate fields sized for ECDSA, appliances that reject chains above an undocumented limit, protocol messages that fragment unexpectedly, smartcards without the storage for a post-quantum credential, and hardware security modules whose firmware supports the algorithm in a version the organisation has not yet deployed.

Two consequences follow. First, an inventory of where cryptography sits is more valuable at this stage than an algorithm decision, which is why a cryptographic bill of materials precedes selection. Second, testing should begin before selection is final, because the constraints discovered in test frequently determine which parameter set is viable.

Most current deployments use hybrid key establishment, combining ML-KEM with a classical algorithm so that the connection remains secure if either component fails. That approach, and the separate question of composite certificates, is a design decision in its own right and is covered separately.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services and critical national infrastructure.

We assess which parameter sets an estate can actually support, through our PKI health check, and design the certificate hierarchy, hardware security module configuration and certificate lifecycle management capability required to deploy them. As a vendor-neutral consultancy, our algorithm and product recommendations follow from the constraints of the estate rather than from a partner's roadmap.

For the wider picture of what is being replaced, see our analysis of which cryptographic algorithms quantum computing breaks.

‍