Quantum Computing vs Cryptography: What You Need to Know Before 2030

Quantum Computing vs Cryptography: What You Need to Know Before 2030

RSA and elliptic-curve cryptography protect most of the internet's private conversations, software updates, banking sessions, and identity tokens. They work because factoring a large number or solving a discrete logarithm is impractical on classical computers. A sufficiently powerful quantum computer changes that assumption. You do not need a quantum computer in your data center to be affected. You need to know which systems depend on algorithms that a quantum machine can break, and how to replace them before the pressure becomes urgent.

Shor's Algorithm, Without the Hype

Shor's algorithm is a quantum routine for finding the period of a mathematical function. That sounds abstract, but the period reveals the factors of an integer. Factor the integer and RSA's private key falls out. A related quantum approach solves the discrete logarithm problem, which breaks Diffie-Hellman, DSA, ECDSA, and EdDSA. In other words, Shor's algorithm attacks the public-key cryptography that handles key exchange and digital signatures, not the symmetric encryption that protects the actual data after keys are established.

Building a machine that can run Shor's algorithm at useful scale is hard. It requires error correction, stable qubits, and a large number of physical qubits to create a single reliable logical qubit. Estimates vary widely by architecture, but breaking RSA-2048 could require millions of physical qubits and significant error-correction overhead. That may be years or decades away. The important point is not the exact date. It is the migration time. If it takes a decade to inventory, test, and replace cryptography across a large organization, waiting until a quantum computer exists means starting too late.

Grover's Algorithm and Symmetric Cryptography

Shor gets the headlines, but Grover's algorithm matters too. Grover provides a quadratic speedup for unstructured search. It does not break AES the way Shor breaks RSA, but it reduces security margins. In an idealized model, a 128-bit symmetric key offers roughly 64-bit quantum security under Grover's attack. Real-world quantum parallelization and error correction make large-scale Grover attacks difficult, but the conservative response is simple: use AES-256 and SHA-384 or SHA-512 for systems that need long-term protection.

This distinction matters. A typical TLS connection uses ECDHE for key exchange, RSA or ECDSA for authentication, and AES-GCM for bulk data encryption. A quantum computer threatens the handshake and the signature, not necessarily the AES layer itself. Once the handshake is broken or a private key is recovered, however, the encrypted session may be exposed. Symmetric cryptography is not the main crisis, but it is part of the risk surface.

Harvest Now, Decrypt Later

The most immediate threat is not a quantum computer sitting in your data center. It is an adversary recording encrypted traffic today and storing it until a quantum computer can decrypt it. This is called harvest now, decrypt later. It affects data with a long confidentiality lifetime: medical records, government secrets, legal documents, intellectual property, financial histories, and long-lived credentials. If a secret must remain secret for 10, 20, or 30 years, and migration takes 5 to 10 years, the clock is already running.

If your data must stay confidential longer than it will take to migrate, you are already in the post-quantum transition whether you have started or not.

What Actually Breaks

Not everything breaks. Public-key algorithms used for key establishment and digital signatures are the primary targets:

• RSA for encryption, key transport, and signatures.
• Diffie-Hellman and ECDH for key exchange.
• DSA, ECDSA, and EdDSA for digital signatures.
• Elliptic-curve cryptography in certificates, VPNs, SSH, code signing, and messaging.

Symmetric encryption and hash functions are more resilient, but their security levels should be chosen with quantum margins in mind. This distinction tells you where to focus first: certificates, TLS, VPNs, SSH, code-signing pipelines, hardware security modules, and identity systems.

Post-Quantum Cryptography Is Already Standardized

You do not have to invent new math. NIST has standardized post-quantum algorithms. FIPS 203 specifies ML-KEM, based on CRYSTALS-Kyber, for key encapsulation. FIPS 204 specifies ML-DSA, based on CRYSTALS-Dilithium, for digital signatures. FIPS 205 specifies SLH-DSA, based on SPHINCS+, as a hash-based signature backup. These algorithms are designed to run on classical computers and can be deployed in software and hardware.

Real deployments are already appearing. Chrome and other browsers have tested hybrid key exchange that combines X25519 with ML-KEM. Signal uses PQXDH for post-quantum key agreement. Apple's iMessage added PQ3. Cloud providers offer hybrid TLS and post-quantum VPN options. The transition has started, but most enterprises are still early.

Why Migration Is Harder Than Swapping an Algorithm

Cryptography is buried in more places than most teams expect. It lives in TLS terminators, load balancers, API gateways, VPN concentrators, SSH clients, code-signing services, certificate authorities, HSMs, smart cards, firmware update systems, databases, backups, and partner integrations. Some systems cannot be patched. Some vendors do not support post-quantum cryptography yet. Some hardware has fixed crypto accelerators. Some protocols have size limits that larger post-quantum keys and signatures stress.

That is why cryptographic agility matters. You need the ability to inventory, prioritize, test, and replace algorithms without rewriting entire systems. A crypto-agile architecture separates policy from implementation, supports multiple algorithms at once, and makes hybrid modes possible during migration.

A Practical Roadmap to 2030

Start with visibility, then move to action. A realistic plan looks like this:

1. Build a cryptographic inventory. Find where RSA, ECC, Diffie-Hellman, and hash functions are used. Include certificates, protocols, libraries, hardware, and third-party services.
2. Classify data by confidentiality lifetime. Prioritize anything that must stay secret beyond 2030 or has a long retirement tail.
3. Patch and upgrade crypto libraries. Enable TLS 1.3, modern cipher suites, and hybrid post-quantum key exchange where available.
4. Adopt post-quantum key exchange first. Hybrid modes reduce risk without forcing a full break from classical cryptography.
5. Plan signature migration. Signatures are harder because certificates, code signing, and firmware need long-term trust and compatibility.
6. Test performance and size impacts. Post-quantum keys and signatures are often larger. Check MTU limits, TLS handshake sizes, HSM capacity, and update payloads.
7. Set vendor requirements. Ask hardware, cloud, and software vendors for post-quantum roadmaps, crypto-agility features, and compliance timelines.
8. Rehearse the switch. Run tabletop exercises and staged rollouts. The goal is not a big-bang migration but a controlled, reversible transition.

What to Do Before 2030

Do not panic, but do not wait for a headline that says a quantum computer has broken RSA. By then, the migration window may already be closing. Focus on the systems that protect long-lived secrets and trust: TLS, VPNs, SSH, code signing, identity, and firmware updates. Use AES-256 for symmetric encryption. Deploy hybrid post-quantum key exchange where you can. Inventory classical public-key dependencies. Build crypto agility into procurement and architecture. The organizations that treat post-quantum cryptography as a multi-year engineering program, not a last-minute patch, will be the ones that avoid the worst disruption.

The Bottom Line

Quantum computing does not break all cryptography. It breaks the public-key algorithms that underpin key exchange and digital signatures, and it weakens symmetric cryptography enough to justify larger keys. The exact date of a cryptographically relevant quantum computer is uncertain, but the harvest-now-decrypt-later threat is real today. If your data, software, or identity systems must remain trustworthy into the 2030s, the migration has already begun. The work is not exotic. It is inventory, prioritization, standardization, testing, and disciplined replacement—done before the pressure becomes urgent.

Photo: Ludovic Delot / Pexels