Post-Quantum Cryptography: What Every Developer Needs to Know Now

This is not a future problem. It is a present problem with a future deadline — and the deadline may be earlier than your organization's security planning assumes.

Why Your Current Cryptography Will Break

RSA, ECDSA, ECDH, and Diffie-Hellman key exchange all derive their security from the computational difficulty of two mathematical problems: integer factorization and the discrete logarithm problem. Classical computers cannot solve these efficiently for the key sizes in common use.

Shor's algorithm, running on a sufficiently large fault-tolerant quantum computer, solves both problems in polynomial time. A quantum computer with approximately 4,000 logical qubits (roughly 4 million physical qubits with current error rates) could break RSA-2048 in hours. AES-128 is weakened by Grover's algorithm to an effective 64-bit security level — still secure, but AES-256 becomes the minimum for long-term security.

We do not have that quantum computer today. But the community has identified the right planning horizon: approximately 2030–2035 for cryptographically relevant quantum computing, with significant uncertainty in both directions.

The Harvest Now, Decrypt Later Attack

Here is why you need to act before quantum computers exist: adversaries can record encrypted traffic today and decrypt it when quantum hardware is available. This is called a harvest-now-decrypt-later (HNDL) or store-now-decrypt-later attack.

Implications:

Any data encrypted today that must remain confidential for 10+ years is already at risk
Government communications, medical records, financial transactions, intellectual property
TLS-encrypted traffic in transit is being recorded by nation-state actors

The NSA and CISA began recommending post-quantum migration in 2022. The EU's ENISA issued similar guidance. This is not paranoia — it is documented threat intelligence.

NIST Post-Quantum Standards: What Was Finalized

In August 2024, NIST finalized its first post-quantum cryptography standards. These are the algorithms to migrate to:

FIPS 203 — ML-KEM (Module-Lattice Key Encapsulation Mechanism) Formerly known as CRYSTALS-Kyber. Used for key exchange and key encapsulation. This replaces ECDH and RSA key exchange. Security based on the hardness of the Module Learning With Errors (MLWE) problem. Recommended for most use cases.

Key sizes (Kyber-768, ~128-bit post-quantum security):
Public key:  1,184 bytes
Private key: 2,400 bytes
Ciphertext:  1,088 bytes

Compare to ECDH P-256:
Public key:  64 bytes

The larger key sizes have implications for TLS handshake performance and certificate chain sizes.

FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm) Formerly CRYSTALS-Dilithium. Used for digital signatures. Replaces ECDSA and RSA signatures.

FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) Formerly SPHINCS+. Hash-based signatures — security relies only on the security of the hash function, not any algebraic structure. Larger and slower than ML-DSA but with the most conservative security assumptions.

In development — FN-DSA (FALCON) Lattice-based signature with smaller signatures than Dilithium but more complex implementation requirements. NIST is finalizing this separately.

Migration Strategy for Developers

Immediate actions (now):

Inventory your cryptography: Document every place in your systems that uses RSA, ECDSA, ECDH, or DH. TLS certificates, code signing keys, SSH keys, JWT signing, encrypted data at rest, encrypted data in transit.

Prioritize long-lived secrets: Data that must remain confidential past 2030, root CA keys with long validity periods, and master encryption keys for data at rest.

Enable hybrid key exchange in TLS: Chrome, Firefox, and major TLS libraries now support X25519Kyber768 — a hybrid that runs both ECDH and Kyber simultaneously. If either is secure, the key exchange is secure. This provides post-quantum protection for TLS traffic today with no backward compatibility cost.

# Nginx — enable hybrid post-quantum key exchange
ssl_ecdh_curve X25519Kyber768Draft00:X25519:prime256v1;

Medium-term (2025–2027):

Migrate to ML-KEM for new key exchange: As library support matures (OpenSSL 3.5+ includes ML-KEM), begin migrating new systems to post-quantum key exchange by default.

Plan certificate migration: Certificate authorities are beginning to issue ML-DSA certificates. Plan the migration from RSA/ECDSA certificates in your PKI.

Libraries and support:

OpenSSL 3.5+: Supports ML-KEM and ML-DSA
BoringSSL: Google's fork includes post-quantum support
liboqs (Open Quantum Safe): Reference implementations of all NIST candidates
Go 1.23+: x/crypto package includes experimental ML-KEM
Cloudflare: Already deploying hybrid post-quantum TLS by default

What Stays the Same

AES (with 256-bit keys) remains quantum-resistant. SHA-256 and SHA-3 remain quantum-resistant (Grover's algorithm provides at most a quadratic speedup, effectively halving security bits). Symmetric cryptography requires only a key-size increase, not an algorithm change.

The Bottom Line for Your Planning

If you are a developer at an organization handling data that needs to stay confidential past 2030, post-quantum migration is not optional. The first step — enabling hybrid TLS — can be done this week with major CDN and load balancer providers. The full migration is a multi-year project that needs to start now.

The developers and security teams who build post-quantum expertise now will be indispensable within five years.