NIST and the Post-Quantum Cryptography Standards

Why Quantum Computing Threatens Cryptography

Most internet security - HTTPS, banking, VPNs, digital signatures - relies on two mathematical assumptions:

1. Factoring large numbers is hard (RSA, used for key exchange)
2. Solving discrete logarithm problems is hard (ECC, used in TLS and SSH)

Shor’s algorithm, running on a sufficiently large fault-tolerant quantum computer, solves both problems in polynomial time. A quantum computer with roughly 4000 logical qubits could break RSA-2048 in hours.

We don’t have that computer yet. But encrypted data stolen today can be decrypted later - the “harvest now, decrypt later” attack. Nation-states are almost certainly harvesting encrypted traffic now, betting on future quantum capability.

NIST’s Competition

In 2016, NIST announced a competition for post-quantum cryptographic algorithms. Over 80 candidate algorithms were submitted. After three rounds of public cryptanalysis, four families survived:

Algorithm	Type	Based on
CRYSTALS-Kyber	Key encapsulation	Lattice (Module-LWE)
CRYSTALS-Dilithium	Digital signature	Lattice (Module-LWE)
FALCON	Digital signature	Lattice (NTRU)
SPHINCS+	Digital signature	Hash functions

Kyber and Dilithium are the primary recommendations. SPHINCS+ is a conservative backup based on well-understood hash function security.

The 2024 Standards

NIST published four final standards in August 2024:

• FIPS 203 (ML-KEM, based on Kyber) - key encapsulation for TLS and similar protocols
• FIPS 204 (ML-DSA, based on Dilithium) - digital signatures
• FIPS 205 (SLH-DSA, based on SPHINCS+) - hash-based signatures
• FIPS 206 (FN-DSA, based on FALCON) - lattice-based digital signatures

These replace RSA and ECDSA in security protocols.

What Migration Looks Like

The migration is one of the largest infrastructure updates in internet history. Every TLS library, every HSM, every government system needs updating.

# Example: Generating ML-KEM (Kyber) keys with liboqs-python
import oqs

# Key generation
kem = oqs.KeyEncapsulation('ML-KEM-768')
public_key = kem.generate_keypair()

# Encapsulation (sender)
ciphertext, shared_secret_sender = kem.encap_secret(public_key)

# Decapsulation (receiver)
shared_secret_receiver = kem.decap_secret(ciphertext)

assert shared_secret_sender == shared_secret_receiver
print("Key exchange successful")
print(f"Key length: {len(shared_secret_sender)} bytes")

Libraries adding post-quantum support:

• OpenSSL 3.x with OQS provider
• BoringSSL (Google) - Kyber in Chrome 124+
• wolfSSL - full FIPS 203/204/205 support
• AWS-LC - Amazon’s fork with PQC support

Industry Timelines

US Government (NSA CNSA 2.0):

• 2025: Software and firmware should be PQ-ready
• 2030: Network equipment must use PQC
• 2033: All systems must use PQC only

Financial sector:

• SWIFT began PQC testing in 2023
• Major banks running hybrid classical+PQC in parallel during transition

Cloud providers:

• AWS KMS: ML-KEM support in 2024
• Google Cloud: Kyber in TLS experiments from 2022
• Azure: PQC roadmap tied to FIPS 203 finalization

The Relevance to Quantum Computing

This is the clearest commercial signal yet that quantum computing is taken seriously. Governments and enterprises are spending billions to migrate cryptography in response to a threat that does not yet exist.

Quantum computers capable of breaking RSA-2048 require:

• ~4000 logical qubits
• Each logical qubit requires ~1000 physical qubits (with current error rates)
• That is ~4 million physical qubits

Current state of the art: ~1000-2000 physical qubits with high error rates. We are likely 10-20 years from cryptographically relevant quantum computers - but the migration needs to happen before they arrive.

Further Reading

• NIST PQC standards
• Open Quantum Safe project - open-source PQC library
• Our glossary: Post-Quantum Cryptography, Shor’s Algorithm