Quantum Computing and the Coming Cryptographic Reckoning

The Problem Isn’t Theoretical Anymore

In 2023, IBM deployed Condor — a 1,121-qubit processor. In 2024, Google’s Willow chip demonstrated below-threshold error correction for the first time: increasing qubit count actually reduced errors, reversing the scaling problem that plagued quantum computing for decades.

We don’t yet have a Cryptographically Relevant Quantum Computer (CRQC) — one capable of running Shor’s algorithm at the scale needed to break RSA-2048. Current estimates place that milestone somewhere between 2030 and 2040. But for security architects, “somewhere in the next 10–15 years” means the time to act is now, not when the first CRQC powers on.

Why? Because of Harvest Now, Decrypt Later (HNDL).

Harvest Now, Decrypt Later

Nation-state adversaries are already intercepting and storing encrypted traffic — government communications, financial transactions, critical infrastructure telemetry — that they cannot currently decrypt. They’re betting that a CRQC will eventually let them read it.

If your encrypted data needs to remain confidential for more than 10 years, it is already at risk.

This is not speculation. NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), released in 2022, sets 2030 as the deadline for transitioning national security systems to post-quantum cryptography. The deadline acknowledges that adversaries are harvesting now.

[Today]          [~2032?]
TLS traffic  →   CRQC decrypts  →  Plaintext exposed
harvested now    Shor's algorithm

What Quantum Computers Actually Break

Shor’s Algorithm (1994)

Peter Shor’s algorithm runs on a quantum computer and can factor large integers in polynomial time. This directly breaks:

RSA: Security relies on the hardness of factoring large semiprimes. A 4096-qubit fault-tolerant quantum computer could factor RSA-2048 in roughly 8 hours.
ECC (Elliptic Curve Cryptography): Security relies on the elliptic curve discrete logarithm problem. Shor’s algorithm solves this too.
Diffie-Hellman key exchange: Same mathematical structure, same vulnerability.

Everything that secures the internet today — TLS 1.3, SSH, S/MIME, code signing certificates, PKI — depends on RSA or ECC. All of it breaks.

Grover’s Algorithm

Grover’s algorithm provides a quadratic speedup for searching unstructured databases. Applied to symmetric cryptography:

AES-128 drops to effectively 64-bit security
AES-256 drops to effectively 128-bit security
SHA-256 has its collision resistance halved

Fix for symmetric: Double key lengths. AES-256 and SHA-384 remain secure post-quantum.

Algorithm      | Classical Security | Quantum Security | Status
RSA-2048       | 112 bits           | ~0 bits          | BROKEN
ECC-256        | 128 bits           | ~0 bits          | BROKEN
AES-128        | 128 bits           | ~64 bits         | WEAKENED
AES-256        | 256 bits           | ~128 bits        | SECURE
SHA-256        | 128-bit collision  | ~64-bit collision | WEAKENED
SHA-384        | 192-bit collision  | ~96-bit collision | SECURE

NIST Post-Quantum Standardisation

NIST ran an 8-year competition (2016–2024) to standardise post-quantum cryptographic algorithms. In August 2024, the first three standards were finalised:

ML-KEM (FIPS 203) — Key Encapsulation

Formerly CRYSTALS-Kyber. Replaces RSA and ECDH for key exchange. Based on the Module Learning With Errors (MLWE) problem — believed to be resistant to both classical and quantum attacks.

# Conceptual usage (using a PQC library like liboqs-python)
from oqs import KeyEncapsulation

# Server generates keypair
kem = KeyEncapsulation('ML-KEM-768')
public_key = kem.generate_keypair()

# Client encapsulates a shared secret
ciphertext, shared_secret_client = kem.encap_secret(public_key)

# Server decapsulates
shared_secret_server = kem.decap_secret(ciphertext)

# shared_secret_client == shared_secret_server
# Now use this as input to AES-256-GCM key derivation

ML-DSA (FIPS 204) — Digital Signatures

Formerly CRYSTALS-Dilithium. Replaces RSA-PSS and ECDSA for signatures. Used for code signing, TLS certificates, and document signing.

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

Formerly SPHINCS+. Conservative hash-based alternative to ML-DSA. Larger signature sizes but security relies only on hash function security — minimal mathematical assumptions.

Hybrid Cryptography: The Transition Strategy

You can’t flip a switch and change the world’s PKI overnight. The current recommended approach is hybrid cryptography: combining classical and post-quantum algorithms so that security holds against both classical and quantum adversaries simultaneously.

TLS Hybrid Key Exchange:
  ECDH(P-256) + ML-KEM-768
  → Combined key material fed into HKDF
  → Session keys secure against both

Chrome shipped X25519+ML-KEM hybrid key exchange in 2024. OpenSSH 9.0 added sntrup761x25519-sha512@openssh.com. The migration is happening in the background of software you already use.

OT/ICS: The Harder Problem

Industrial control systems present unique challenges for post-quantum migration that make the IT transition look straightforward.

Why OT is Different

Constrained hardware: PLCs, RTUs, and embedded safety controllers run on processors from the 1990s–2000s. A Siemens S7-300 runs on a 32-bit processor at 40 MHz. ML-KEM key generation is computationally expensive — it may simply not run on these devices.

Long lifecycles: IT infrastructure refreshes every 3–5 years. OT hardware routinely runs for 15–25 years. A SCADA system commissioned today may still be running in 2045 — well into the CRQC era.

Safety implications: Cryptographic migration in an OT environment requires testing, validation, and often plant downtime. For continuous-process industries (refineries, power generation), scheduled downtime is measured in millions of dollars per day.

Protocol limitations: IEC 61850, DNP3, Modbus TCP, and PROFINET were designed with minimal or no cryptographic agility. Updating them requires protocol stack replacements across potentially thousands of field devices.

Practical OT Migration Path

Tier 1 — Act Now (no hardware changes needed):
  - Migrate data-at-rest encryption to AES-256
  - Migrate authentication hashes to SHA-384
  - Replace RSA-2048 certificates with ML-DSA-65 where supported

Tier 2 — During Next Maintenance Window:
  - Replace historian and SCADA server TLS with hybrid key exchange
  - Update PKI root certificates to include PQC algorithms
  - Deploy quantum-safe VPN gateways at OT/IT boundary

Tier 3 — Hardware Refresh Cycle:
  - Specify PQC support as procurement requirement for new field devices
  - Require IEC 62443-4-2 PQC compliance in vendor contracts
  - Begin phased replacement of cryptographically limited legacy controllers

Cryptographic Agility: Building for the Unknown

The hardest lesson from the RSA/ECC era is that we hardcoded cryptographic algorithms everywhere. When an algorithm needs replacing, the cost is enormous because cryptography was treated as a solved problem, not a component to be upgraded.

Cryptographic agility means building systems where the algorithm is a configuration parameter, not a compile-time constant:

# Cryptographically agile key derivation
class SecureChannel:
    def __init__(self, kem_algorithm: str = "ML-KEM-768",
                       sig_algorithm: str = "ML-DSA-65",
                       sym_algorithm: str = "AES-256-GCM"):
        self.kem = kem_algorithm
        self.sig = sig_algorithm
        self.sym = sym_algorithm

    def negotiate(self, peer_capabilities: list[str]) -> dict:
        # Prefer PQC, fall back to hybrid, fall back to classical
        preferred_order = [
            "ML-KEM-768+X25519",  # hybrid
            "ML-KEM-768",          # pure PQC
            "X25519",              # classical fallback
        ]
        for alg in preferred_order:
            if alg in peer_capabilities:
                return {"kem": alg, "sym": self.sym}
        raise ValueError("No common algorithm")

This is not a future concern for new projects. This is a design requirement today for any system with a service life extending past 2030.

The Timeline

Year	Milestone
2022	NSA CNSA 2.0 published — 2030 migration deadline for national security systems
2024	NIST finalises ML-KEM, ML-DSA, SLH-DSA standards
2025	Chrome, Firefox, OpenSSH shipping hybrid PQC by default
2026–2028	Enterprise PKI migration begins at scale; cloud providers default to hybrid TLS
2030	NSA deadline; EU NIS2 likely mandates PQC for critical infrastructure
2032–2038	Estimated first CRQC capable of breaking RSA-2048

What to Do Right Now

Inventory your cryptographic dependencies — where is RSA/ECC used? TLS certificates, SSH keys, code signing, VPN, database encryption, application-layer encryption?
Classify data by required confidentiality lifetime — data that must remain secret for 10+ years is at HNDL risk today
Move symmetric to AES-256 immediately — free win, no algorithmic migration needed
Pilot ML-KEM hybrid TLS on non-critical services — gain operational experience before critical migrations
Update certificate policies to require ML-DSA for new certificate issuance starting 2026
Engage OT vendors now — ask for post-quantum roadmaps; make PQC a procurement criterion

The quantum threat is not a fire drill. The standards are final, the timeline is credible, and the adversaries are already collecting. Cryptographic agility built into systems today is the difference between a managed migration and a crisis response.