Post-quantum cryptography: NIST FIPS 203, 204 and 205

What post-quantum cryptography is

Post-quantum cryptography (PQC) means public-key algorithms designed to stay secure even against a large quantum computer. Despite the name, it is not quantum technology: PQC runs on ordinary CPUs, phones and servers, and travels over existing networks. It replaces RSA and elliptic curve cryptography for two jobs: key establishment (agreeing a shared secret) and digital signatures (proving who signed something). Do not confuse it with quantum key distribution, which uses special physics hardware.

The US National Institute of Standards and Technology (NIST) ran an open, multi-year public competition in which cryptographers worldwide submitted and attacked candidate algorithms. Several candidates were broken along the way, which is exactly what such a process is for. In August 2024 NIST published the first three standards.

The three standards

• ML-KEM is a key encapsulation mechanism (KEM). Instead of both sides contributing to a Diffie-Hellman calculation, one side encapsulates a random secret using the other's public key. It is fast, but public keys and ciphertexts are around a kilobyte, much larger than the 32 bytes of an X25519 key.
• ML-DSA is the expected default for most signatures. Signatures are a few kilobytes, which affects certificate chains and constrained devices.
• SLH-DSA relies only on hash functions, a very well understood foundation. Signatures are larger and slower, so it suits cases such as firmware signing where confidence matters more than size.

NIST has also selected HQC, based on error-correcting codes, as a backup KEM so that not everything depends on lattices, and is standardising FN-DSA (from Falcon) for compact signatures. Stateful hash-based signatures (LMS and XMSS, in NIST SP 800-208) are already approved for uses such as firmware where the signer can carefully track state.

Hybrid deployment

New algorithms deserve caution, so many deployments use hybrid key exchange: a classical exchange such as X25519 and ML-KEM run together, and the session key depends on both. An attacker must break both to read the traffic. Major browsers, content delivery networks and recent versions of OpenSSL and OpenSSH already support hybrid groups such as X25519MLKEM768 in TLS 1.3 and mlkem768x25519-sha256 in SSH. You can check what your own tools support:

openssl version
openssl list -kem-algorithms
openssl s_client -connect example.com:443 -groups X25519MLKEM768
ssh -Q kex

Practical considerations

• Size: larger keys and signatures can break assumptions in protocols, middleboxes and constrained IoT links. Test for fragmentation and buffer limits.
• Implementation quality: use well-reviewed libraries and validated modules; never write your own.
• Side channels: implementations must run in constant time and resist timing and power analysis.
• Interoperability: certificate and protocol standards for PQC are still being finalised in some areas, so track IETF work and vendor roadmaps.

Tip: for exams, map names: Kyber became ML-KEM (FIPS 203), Dilithium became ML-DSA (FIPS 204), SPHINCS+ became SLH-DSA (FIPS 205). KEM is for key exchange; DSA is for signatures.

For planning the move across an organisation, see post-quantum migration and crypto agility.