Post-Quantum Cryptography: Migrating Before It's Too Late

The Threat Is Not Future — It's Present

The most common objection to post-quantum migration is: "We don't have quantum computers that can break RSA yet. Why rush?" This misses the real threat.

Harvest Now, Decrypt Later (HNDL) is the strategy where adversaries capture encrypted traffic today and store it, waiting for quantum computers capable of decrypting it. If your encrypted data has value beyond 10-15 years — medical records, government communications, financial data, trade secrets — it's already vulnerable.

NIST finalized three post-quantum cryptographic standards in 2024. The migration window is now.

The New Standards

ML-KEM (FIPS 203) — Key Encapsulation

Replaces RSA and ECDH for key exchange. Based on the Module Learning with Errors (MLWE) problem. Three security levels:

• ML-KEM-512: Roughly equivalent to AES-128 security
• ML-KEM-768: Roughly equivalent to AES-192 security (recommended default)
• ML-KEM-1024: Roughly equivalent to AES-256 security

Key sizes are larger than RSA (public keys around 800-1,500 bytes vs. 256 bytes for ECC), but operations are faster.

ML-DSA (FIPS 204) — Digital Signatures

Replaces RSA and ECDSA for digital signatures. Also based on lattice problems. Signature sizes are larger (2,420-4,627 bytes vs. 64 bytes for Ed25519), but verification is fast.

SLH-DSA (FIPS 205) — Hash-Based Signatures

A conservative alternative to ML-DSA based entirely on hash functions. Larger signatures but relies on minimal cryptographic assumptions. Recommended for applications where long-term security confidence is paramount.

Migration Roadmap

Phase 1: Inventory (Weeks 1-4)

Before changing any code, map every place your system uses cryptography:

• TLS certificates and configurations
• API authentication (JWT signing, OAuth tokens)
• Data encryption at rest (database, file storage)
• Code signing and software update verification
• VPN and SSH configurations
• Third-party integrations that exchange keys

Phase 2: Hybrid Deployment (Months 2-6)

Don't switch entirely to post-quantum algorithms. Deploy hybrid schemes that combine classical and post-quantum algorithms. For TLS, this means using X25519 + ML-KEM-768 key exchange. If the post-quantum algorithm has an undiscovered weakness, the classical algorithm still provides security. If a quantum computer breaks the classical algorithm, the post-quantum algorithm provides security.

Phase 3: Testing and Performance (Months 4-8)

Post-quantum algorithms have different performance characteristics:

• Larger key sizes increase bandwidth usage (critical for IoT and mobile)
• Larger signatures increase certificate chain verification time
• Key generation is generally faster than RSA
• Test thoroughly under production load conditions

Phase 4: Full Migration (Months 8-12)

Once hybrid deployment is stable and tested, begin transitioning to post-quantum-only configurations where appropriate. Maintain hybrid support for backward compatibility during the transition period.

Practical Advice

• Start with TLS. It's the highest-value target and has the best library support (OpenSSL 3.2+, BoringSSL).
• Use liboqs (Open Quantum Safe) for experimental integration. It provides C implementations of all NIST-selected algorithms.
• Don't roll your own. Post-quantum implementations are subtle. Side-channel attacks on lattice-based schemes are an active research area. Use vetted libraries.
• Plan for agility. Design your cryptographic layer to be algorithm-agnostic. The ability to swap algorithms without rewriting application code is the most valuable long-term investment.

The Clock Is Ticking

The NSA's CNSA 2.0 suite requires all national security systems to support post-quantum algorithms by 2030 and use them exclusively by 2033. If the timeline matters for classified systems, it should matter for your production systems too. The migration is complex but well-defined. Start now.