Post-Quantum Cryptography for Builders: What to Do Now

Quantum computers capable of breaking today's cryptography haven't arrived yet, but preparing for them is not a future luxury — it's a decision about your data today. The public-key algorithms we rely on (RSA and ECC) collapse under Shor's algorithm on a sufficiently large quantum computer. This article explains the real threat, the new standards, and what builders can do now without waiting.

Why Now? The Harvest-Now, Decrypt-Later Threat

The danger does not require a quantum computer to exist today. A capable adversary can intercept your encrypted traffic now and store it, then decrypt it years later once quantum computers mature. This is known as harvest-now-decrypt-later. So any data whose confidentiality must last a long time — health records, contracts, government secrets, intellectual property — is at risk from the moment it crosses the network today.

NIST's New Standards

In 2024, NIST published its first formal post-quantum cryptography standards after a multi-year public selection process — the foundation to build on, rather than experimental algorithms:

• ML-KEM (FIPS 203): a key-encapsulation mechanism based on Kyber, replacing RSA/ECDH key exchange — that is, for securing the communication channel.
• ML-DSA (FIPS 204): a digital signature algorithm based on Dilithium, for authenticity and signatures.
• SLH-DSA (FIPS 205): a hash-based signature scheme as a conservative fallback with different security assumptions.

Hybrid Key Exchange

The agreed-upon migration pattern today is not to swap out the classical algorithm immediately, but to combine it with its post-quantum counterpart in a hybrid key exchange: the final key is derived from both. Communications stay secure unless both are broken — this protects you if a weakness emerges in the relatively new post-quantum algorithm, while satisfying compliance requirements that still mandate the classical one.

# Modern TLS libraries expose hybrid PQC key exchange.
# Conceptually, the negotiated group combines a classical
# curve with ML-KEM so the session key needs BOTH broken:

key_exchange_group = X25519MLKEM768   # hybrid: X25519 + ML-KEM-768

# Practical near-term steps for builders:
#  1) Inventory where you use RSA / ECDH / ECDSA today.
#  2) Upgrade to TLS libraries/providers that offer hybrid groups.
#  3) Enable a hybrid group for transport (e.g. X25519MLKEM768).
#  4) Plan ML-DSA for signatures (code signing, tokens) next.
#  5) Prefer crypto-agility: keep algorithms swappable, not hardcoded.

What to Do Now, Practically

1. Inventory your cryptographic assets: where are RSA, ECDH, and ECDSA used across your systems and their communication endpoints?
2. Classify data by how long its confidentiality must hold — long-lived data is the top priority for migration.
3. Enable hybrid key exchange at the transport layer wherever your libraries support it, and start planning for ML-DSA signatures.
4. Adopt crypto-agility: make algorithms swappable via configuration rather than hardcoded.