Post-Quantum Cryptography: NIST PQC Algorithm Overview

The primary near-term risk isn't a working cryptographically relevant quantum computer today — it's 'harvest now, decrypt later': an adversary records encrypted traffic or data now and decrypts it once a capable quantum computer exists in the future. For data with a long confidentiality lifetime (state secrets, health records, long-term intellectual property, anything sensitive for a decade or more), that risk is live today even though the decryption capability isn't, which is why migration planning is a current priority rather than a future one for organizations with that kind of data.

Signatures have a related but distinct concern: a signature only needs to resist forgery for as long as it needs to remain trustworthy, so long-lived code-signing and document-signing infrastructure is a second priority migration target even though it isn't vulnerable to the harvest-now-decrypt-later pattern in the same way.

In August 2024, NIST finalized the first three post-quantum cryptography standards as Federal Information Processing Standards (FIPS), following the multi-round public competition that began in 2016. Each targets a different cryptographic function and is based on structured lattice or hash-based mathematics believed to resist both classical and quantum attack.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, standardized in FIPS 203, formerly known as Kyber) is designed to replace RSA and elliptic-curve Diffie-Hellman for establishing a shared secret between two parties. Rather than a direct drop-in for ECDHE, it's a key encapsulation mechanism (KEM): one party encapsulates a shared secret against the other's public key, and the recipient decapsulates it with their private key.

NIST specifies three parameter sets — ML-KEM-512, ML-KEM-768, and ML-KEM-1024 — offering increasing security margins at increasing computational and bandwidth cost, broadly analogous to choosing between different RSA or ECC key sizes.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204, formerly Dilithium) is the primary general-purpose PQC signature standard, intended as the main replacement for RSA and ECDSA signatures in most contexts, offering a reasonable balance of signature size, key size, and performance.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205, formerly SPHINCS+) takes a deliberately conservative, different mathematical approach: its security relies only on the security of the underlying hash function, rather than on newer lattice-based hardness assumptions. This makes it more conservative — hash-based signatures have a much longer track record of cryptanalytic scrutiny — at the cost of larger signatures and slower signing than ML-DSA. NIST recommends it primarily as a backup standard, for situations where diversity of underlying mathematical assumption is itself valued, or where ML-DSA's lattice-based assumptions are a specific concern.

• •ML-DSA: default choice for most new signature use cases needing PQC
• •SLH-DSA: conservative backup, larger signatures and slower operations, valuable specifically for its different (hash-based) security assumption
• •A fourth algorithm, HQC, was selected in 2025 as a backup KEM based on a different mathematical approach (code-based cryptography) to diversify away from ML-KEM's lattice assumption, with standardization expected in the following years

The near-universal recommendation for the current transition period is hybrid key exchange: combine a classical algorithm (X25519 or ECDHE) with a post-quantum KEM (ML-KEM) in the same handshake, deriving the session key from both. This way, an implementation flaw or unexpected weakness discovered in the newer PQC algorithm doesn't regress security below what classical cryptography already provides — the connection remains at least as strong as the classical component alone.

Major browsers and TLS libraries have already begun shipping hybrid X25519+ML-KEM key exchange as an option or default, and this pattern is the practical entry point for most organizations rather than a full cutover to PQC-only cryptography.

# Recent OpenSSL/BoringSSL builds expose hybrid groups by name;
# availability depends on your library version.
openssl list -kem-algorithms

# Example: requesting a hybrid X25519 + ML-KEM group where supported
openssl s_client -connect example.com:443 -groups X25519MLKEM768

For most organizations, the immediate work isn't deploying PQC everywhere today — it's inventory and planning. You cannot migrate cryptography you don't know you're using.

• •Inventory where RSA, ECDH, and ECDSA are used across your infrastructure — TLS termination, VPNs, code signing, document signing, embedded devices
• •Identify data and communications with long confidentiality lifetimes — these are the priority for harvest-now-decrypt-later risk
• •Identify long-lived signing infrastructure (firmware signing, root CAs, code-signing keys) as a second priority track
• •Track vendor and library roadmaps for ML-KEM/ML-DSA support rather than attempting custom implementations — use vetted, standard library implementations only
• •Favor hybrid classical+PQC deployment for the current transition period rather than jumping straight to PQC-only
• •Revisit crypto-agility in your architecture — systems that can swap algorithms without major rework will make this and future transitions cheaper