Post-Quantum Cryptography: What Developers Need to Do Now

Quantum computers don't yet threaten your encryption. A quantum computer capable of breaking RSA-2048 would need millions of error-corrected logical qubits — we have hundreds of noisy physical ones. But here's the problem: adversaries may be collecting encrypted data right now with the intent to decrypt it later, once quantum hardware matures. And migrating cryptographic infrastructure takes years.

This is why 2024's NIST post-quantum cryptography standards matter to developers today, not in 2035.

The Actual Threat: Shor's Algorithm

In 1994, Peter Shor proved that a quantum computer can factor large integers in polynomial time O((log N)³). This breaks RSA, whose security relies on factoring being hard. The same algorithm — with minor modifications — breaks elliptic curve cryptography (ECC), which underlies ECDSA and ECDH.

What breaks:

• RSA (encryption, signatures)
• ECDSA (signing — used in TLS, SSH, code signing, Bitcoin)
• ECDH (key exchange — used in TLS, Signal, WhatsApp, iMessage)
• Diffie-Hellman (key exchange)

What doesn't break:

• AES-256 (symmetric encryption) — Grover's algorithm only provides a quadratic speedup, reducing effective key strength from 256 to 128 bits. This is manageable.
• SHA-256, SHA-3 (hash functions) — same: Grover provides minor speedup, security halves, still strong enough with current key sizes
• HMAC — safe
• Argon2, bcrypt (password hashing) — safe

The bottom line: asymmetric cryptography needs replacing; symmetric cryptography needs a key size bump (AES-128 → AES-256).

Harvest Now, Decrypt Later

The threat isn't "quantum computers will break encryption next year." The threat is:

1. An adversary captures and stores your encrypted TLS traffic today
2. In 2032–2040, they run Shor's algorithm on it
3. They decrypt everything retroactively

This attack — called "harvest now, decrypt later" or HNDL — is already happening. NSA and other intelligence agencies are almost certainly storing large volumes of encrypted traffic. The 2022 NSA advisory explicitly warned about this.

Data that needs protection today against HNDL:

• State secrets, classified government data
• Long-lived personal data (medical records, identity documents)
• Financial data with long regulatory retention requirements
• Trade secrets and IP
• Password databases (though bcrypt/Argon2 are safe)

Data that doesn't need immediate worry:

• Session tokens (short-lived, worthless in 10 years)
• Ephemeral chat messages (unless you're a high-value target)
• Public information

NIST's Post-Quantum Standards (2024)

After an 8-year competition, NIST finalized three post-quantum cryptography algorithms in August 2024:

ML-KEM (CRYSTALS-Kyber) — Key Encapsulation

• Replaces: RSA key exchange, ECDH
• Security basis: Module Learning With Errors (MLWE) problem — believed hard for both classical and quantum computers
• Performance: Fast, small keys (~800 bytes for KEM-768), fast operations
• Use for: TLS key exchange, encrypted key wrapping, hybrid encryption schemes

# Python example using pqcrypto library
from pqcrypto.kem.kyber768 import generate_keypair, encapsulate, decapsulate

public_key, secret_key = generate_keypair()

# Sender encapsulates a shared secret
ciphertext, shared_secret_sender = encapsulate(public_key)

# Receiver decapsulates
shared_secret_receiver = decapsulate(secret_key, ciphertext)

assert shared_secret_sender == shared_secret_receiver
# Now use shared_secret as AES key

ML-DSA (CRYSTALS-Dilithium) — Digital Signatures

• Replaces: ECDSA, RSA-PSS for signing
• Security basis: MLWE + MSIS problems
• Performance: Moderate key sizes (~1,312 bytes public key), fast signing
• Use for: Code signing, TLS certificates, document signing, JWT signatures

from pqcrypto.sign.dilithium3 import generate_keypair, sign, verify

public_key, secret_key = generate_keypair()

message = b"Deploy to production"
signature = sign(message, secret_key)

# Verify
assert verify(message, signature, public_key)

SLH-DSA (SPHINCS+) — Hash-Based Signatures

• Replaces: ECDSA as a conservative backup
• Security basis: Hash functions only — the most conservative choice
• Performance: Larger signatures (~8–50 KB), slower signing
• Use for: High-assurance signing where key reuse is a concern, long-term document signing

NIST also standardized FALCON (FN-DSA) — a lattice signature scheme with compact signatures, suitable for constrained environments like IoT.

What to Do Now: A Tiered Action Plan

Tier 1 — Do This Today (Low Effort, High Impact)

Audit your cryptographic inventory. You cannot migrate what you haven't catalogued. Document:

• Where does your application use TLS? (Most frameworks handle this)
• Where do you generate or verify signatures? (JWTs, code signing, PDF signing)
• Where do you use asymmetric key exchange? (RSA-wrapped AES keys, SSH)
• Which libraries are you using? (OpenSSL, BouncyCastle, AWS KMS, etc.)

Upgrade AES-128 to AES-256. This is low-risk and immediate. AES-256 halves to 128-bit security against Grover — still plenty safe.

Enable TLS 1.3 everywhere. TLS 1.3 uses forward secrecy by default (ECDHE), meaning past sessions can't be decrypted even if the long-term key is compromised. This partially mitigates HNDL for TLS traffic.

Tier 2 — Plan for the Next 6–18 Months

Adopt hybrid key exchange in TLS. The TLS working group has standardized X25519Kyber768 — a hybrid scheme that uses both classical ECDH and ML-KEM. Google Chrome, Cloudflare, and AWS already support it. This protects against HNDL while maintaining classical security:

# Nginx with OpenSSL 3.x + oqs-provider (Open Quantum Safe)
ssl_ecdh_curve X25519Kyber768;  # hybrid classical + PQC

Replace RSA/ECDSA in new systems with ML-DSA. For anything greenfield — new microservices, new JWT implementations, new SSH deployments — use ML-DSA (Dilithium3 or Dilithium5) instead of ECDSA-256.

Update your TLS certificate pipeline. Most public CAs don't yet issue PQC certificates, but you can use ML-DSA for internally-signed certificates and service mesh certificates today.

Tier 3 — Long-Term Migration (1–5 Years)

Full PKI migration. Replace your RSA/ECC certificate hierarchy with PQC-based CA infrastructure. This is the hardest part — hardware security modules (HSMs), automated certificate rotation, and certificate chains all need updating.

Hardware and embedded devices. IoT and embedded devices often can't be patched remotely and have 10+ year lifetimes. Audit any such devices that rely on RSA or ECDSA for authentication.

Key management systems. AWS KMS, Azure Key Vault, HashiCorp Vault — verify their PQC roadmaps and migration timelines.

Library and Framework Support

One-Page Summary

What breaks:    RSA, ECDSA, ECDH, classical DH
What's safe:    AES-256, SHA-256, SHA-3, bcrypt, Argon2
New standards:  ML-KEM (Kyber) for key exchange
                ML-DSA (Dilithium) for signatures
                SLH-DSA (SPHINCS+) for conservative signing

Do today:       Upgrade AES-128 → AES-256
                Enable TLS 1.3 (forward secrecy)
                Audit crypto inventory

Do soon:        Hybrid TLS key exchange (X25519Kyber768)
                ML-DSA for new signature systems

Do in 1-5 yrs:  Full PKI migration to PQC
                Firmware updates for IoT devices

The quantum threat to cryptography is real and the timeline is uncertain — which is exactly why acting now, before quantum computers are capable, is the right call.

Further reading: Quantum computing glossary — Shor's Algorithm · What quantum computers can do today