Post-Quantum Cryptography:
Why You Need to Start Migrating Your Apps Now

The Quantum Threat Explained Simply

Classical computers solve problems that can be broken into steps and executed sequentially (or in parallel but still step-by-step). Quantum computers use quantum mechanical properties — superposition and entanglement — to explore many solution paths simultaneously for certain types of problems.

The relevant threat for cryptography is Shor's algorithm: a quantum algorithm that can factor large integers and solve discrete logarithm problems exponentially faster than classical algorithms. This directly breaks RSA, ECC (Elliptic Curve Cryptography), and Diffie-Hellman key exchange — which rely on the computational difficulty of these very problems.

When cryptographers say "a 2048-bit RSA key is computationally infeasible to break," they mean on a classical computer. A sufficiently powerful quantum computer running Shor's algorithm could break it in hours. The key phrase is "sufficiently powerful" — we're not there yet in 2026. But the trajectory of quantum hardware development means we need to be ready before we get there.

Harvest-Now-Decrypt-Later: Why This Is Urgent Today

Here's the threat that makes post-quantum migration urgent now, before large-scale quantum computers exist: an adversary can record your encrypted traffic today and decrypt it later, when quantum computers are available.

If you're protecting data that will still be sensitive in 10-15 years — medical records, national security communications, financial contracts, intellectual property — an adversary with sufficient resources is potentially recording it now. When quantum computing becomes available at the capability needed to break RSA-2048, they'll have the ciphertext waiting.

The migration timeline for "start now" isn't about protecting against today's quantum computers (which aren't capable of breaking production key sizes). It's about ensuring that data encrypted today can't be decrypted by tomorrow's quantum computers.

NIST's Post-Quantum Standards: ML-KEM, ML-DSA, SLH-DSA

NIST ran a multi-year post-quantum cryptography standardization competition and published its final standards in August 2024. Three standards are now finalized:

ML-KEM (FIPS 203) — formerly Kyber

A Key Encapsulation Mechanism (KEM) based on the Module Learning With Errors (MLWE) problem. Used for key exchange and key establishment — replacing RSA and ECDH. ML-KEM-768 is the recommended variant for most applications (equivalent security to AES-192).

ML-DSA (FIPS 204) — formerly Dilithium

A digital signature scheme based on MLWE. Replaces RSA and ECDSA for code signing, certificate signing, and message authentication. Produces larger signatures than RSA/ECDSA but significantly smaller than hash-based alternatives.

SLH-DSA (FIPS 205) — formerly SPHINCS+

A stateless hash-based digital signature scheme. Larger signatures and slower verification than ML-DSA, but its security relies only on the security of hash functions — considered the most conservative choice if you're skeptical of lattice-based assumptions.

What Breaks When Large-Scale Quantum Arrives

• RSA — all key sizes. RSA-2048, RSA-4096: all broken by Shor's algorithm
• ECC (all curves) — P-256, P-384, P-521, Curve25519: all broken
• Diffie-Hellman — classic DH and ECDH key exchange: both broken
• DSA/ECDSA — all standard digital signature schemes based on discrete log: broken
• All TLS cipher suites that use RSA or ECDH for key exchange: the key exchange step is broken, exposing the session keys to retrospective decryption

What Doesn't Break: AES-256, SHA-3

Grover's algorithm provides a quadratic speedup for searching unstructured data — which means a quantum computer can search a keyspace in the square root of the time a classical computer would take. Against AES-128, this effectively halves the security level (equivalent to AES-64 classically). Against AES-256, it halves to AES-128 — which remains secure.

The practical implication: AES-256 is safe post-quantum. SHA-256 security halves to 128 bits — still generally acceptable but SHA-3-256 or SHA-384 are preferred for new designs. SHA-512 and SHA-3-512 maintain strong security margins.

Hybrid Migration Strategy

The recommended migration approach is hybrid cryptography: combine a classical algorithm with a post-quantum algorithm so that you're protected against both classical attacks (in case post-quantum algorithms turn out to have weaknesses) and quantum attacks (against the classical algorithm). The combined key material is only as weak as the stronger of the two.

For key exchange: combine ECDH (X25519) with ML-KEM-768. For signatures: combine ECDSA/Ed25519 with ML-DSA-65. This is what TLS 1.3 post-quantum extensions do — they add ML-KEM as an additional key share alongside the classical ECDH share.

# Using liboqs Python bindings (Open Quantum Safe project)
import oqs

# ML-KEM-768 key encapsulation
with oqs.KeyEncapsulation("ML-KEM-768") as server:
    public_key = server.generate_keypair()

    # Client side: encapsulate
    with oqs.KeyEncapsulation("ML-KEM-768") as client:
        ciphertext, shared_secret_client = client.encap_secret(public_key)

    # Server side: decapsulate
    shared_secret_server = server.decap_secret(ciphertext)
    # shared_secret_client == shared_secret_server
    # Use this shared secret as input to a KDF for session keys

# In a hybrid scheme, also perform classical ECDH and XOR/combine the outputs
# Security = max(ML-KEM security, ECDH security)

Auditing Your App's Cryptographic Dependencies

Before you can migrate, you need to know where classical asymmetric cryptography is used in your application. The places to look:

• TLS configuration: Check your TLS library version and cipher suite configuration. OpenSSL 3.3+ and BoringSSL (used by Chrome) already support ML-KEM in hybrid mode.
• JWT signing: RS256, ES256, PS256 — all use RSA or ECC. These need to migrate to PQC-safe algorithms when post-quantum JWT standards are finalised.
• SSH keys: RSA and ECDSA SSH host and user keys. OpenSSH 9.0+ added support for FIDO2 and has post-quantum additions in later versions.
• Certificate handling: Code that generates or validates X.509 certificates using RSA/ECC keys.
• Custom crypto: Any in-house implementation of RSA, ECC, or DH.

# Quick audit: find RSA/ECC usage in Python codebase
grep -r "RSA\|rsa\|generate_private_key\|ec\.generate" \
    --include="*.py" ./src/

# Find JWT algorithm settings
grep -r "RS256\|ES256\|PS256\|RS384\|ES384" \
    --include="*.py" --include="*.js" --include="*.ts" ./

# Find hardcoded RSA key sizes (risk: too small)
grep -r "2048\|key_size=1024\|RSA_generate_key" \
    --include="*.py" ./

TLS 1.3 and Post-Quantum Handshakes

The good news on TLS: the post-quantum migration at the TLS layer is largely happening at the library and browser level, not the application level. Chrome enabled hybrid X25519+ML-KEM by default in 2024. OpenSSL 3.3+ supports it. If you're using a modern TLS library and modern browsers, you may already be getting post-quantum key exchange for new connections without application changes.

What you still need to do: ensure your TLS library is current, verify that your certificate validity periods don't outlast the quantum transition timeline (10-year certificates issued today will expire after quantum computers capable of breaking ECC may exist), and plan for certificate migration to PQC-based certificates when CA infrastructure supports it.

Timeline and Compliance Requirements

Key dates to know:

• 2024: NIST FIPS 203, 204, 205, 206 published — PQC standards are final
• 2025: NSA CNSA 2.0 Suite mandates PQC for new national security systems
• 2026-2028: Expected commercial adoption in PKI infrastructure (CAs offering PQC certificates)
• 2030: NSA CNSA 2.0 deadline for all national security systems to use PQC exclusively. NIST recommends industry follow a similar timeline.
• 2035: NIST recommends phasing out classical public key algorithms completely by this date.

For most organisations, the practical action for 2026 is: complete the audit, prioritise high-sensitivity data systems, begin hybrid TLS deployment, and create a roadmap for migrating custom crypto implementations and JWT signing.