Post-Quantum Cryptography, AI and Q-Day: Real Threats, Less Hype

Text graphic on a dark navy background reading Cryptography in the age of AI and quantum. Real threats. Less hype. With labels RSA and ECC: quantum risk, AES 128: still fine, and FIPS 203, 204, 205, over faint hex ciphertext and a lattice dot pattern

If you read the headlines this year, you could be forgiven for thinking encryption is about to fall over. Quantum computers are coming for RSA. AI is learning to do cryptanalysis. Governments are setting hard deadlines. Somewhere in all of that, the phrase post-quantum cryptography went from a niche research topic to a board-level talking point.

Some of that urgency is earned. Some of it is hype, and hype has a cost. I want to walk through both sides honestly: what quantum computers can and can’t break, what AI can and can’t do to the math, and why I think the more immediate danger is sitting somewhere much less exotic. Spoiler: it’s in the code, not the ciphers.

Where this piece shares my own view, I’ll say so plainly. Everything else is sourced and dated, with links inline and a full list at the end.

Two different threats that keep getting lumped together

“AI and quantum” get mentioned in the same breath so often that they start to sound like one threat. They aren’t. They attack different things in different ways.

  • Quantum computing is a threat to specific math. A large, error-corrected quantum computer running Shor’s algorithm would break the public-key systems we use for key exchange and digital signatures: RSA, Diffie-Hellman and elliptic curve cryptography. That’s a real, well understood risk. The open question is when the machine exists, not whether the algorithm works.
  • AI runs on ordinary classical hardware. It doesn’t change the hardness assumptions underneath modern cryptography. As PostQuantum.com explains, well-designed ciphertext looks like random noise, which gives a learning system nothing to learn from. Where AI does help attackers is around the math: side channels, implementation bugs, phishing and, increasingly, finding and exploiting flaws in software.

If you want a refresher on why AI is fundamentally a classical, GPU and network bound workload, I covered that in How AI Really Works and Why AI Is Secretly a Networking Problem. AI is very fast, very parallel computing. It isn’t magic, and it isn’t a quantum computer.

What a quantum computer actually breaks

This is the part that gets flattened most in coverage, so it’s worth being precise.

Shor’s algorithm breaks RSA and elliptic curve cryptography outright once you have a big enough, reliable enough machine. That’s not a weakening. It’s a collapse. Every TLS handshake, VPN tunnel, code signing certificate and SSH key that depends on RSA or ECC is exposed in principle.

Grover’s algorithm is the one people misquote. It offers a square-root speedup on brute force search, which is why you’ll often read that it “halves” the strength of AES and makes AES-128 unsafe. In practice, that speedup is far weaker than it sounds. Filippo Valsorda laid out the numbers in “Quantum Computers Are Not a Threat to 128-bit Symmetric Keys” (April 20, 2026), later covered by Ars Technica:

  • Grover’s iterations must run one after another. Splitting the work across many machines dilutes the speedup instead of preserving it.
  • By his estimate, breaking a single AES-128 key in ten years would take roughly 247 (about 140 trillion) quantum circuits running in parallel, each needing around 724 logical qubits.
  • That attack works out to about 278.5 times more expensive than the 2026 estimate for breaking a 256-bit elliptic curve key with Shor.
  • NIST’s own guidance is that AES-128 will remain secure for decades, and NIST’s transition plan keeps all AES key sizes while retiring the quantum-vulnerable public-key algorithms.

So the asymmetry is the whole story. Public-key cryptography has a genuine quantum problem. Symmetric encryption like AES and hash functions like SHA-256 are, for practical purposes, fine. Some policies, such as the NSA’s CNSA 2.0 suite, require AES-256 anyway, but that’s a conservative “256 bits everywhere” policy choice, not evidence that AES-128 is about to break.

The qubit estimates keep falling, and that’s the honest worry

If I’m going to argue the threat is overhyped, I have to be fair about why serious people are worried. The main reason is that the estimated size of a code-breaking quantum computer keeps shrinking.

  • 2019 to 2025: Google Quantum AI’s Craig Gidney estimated in May 2025 that RSA-2048 could be factored in under a week with fewer than one million noisy qubits. His 2019 estimate with Martin Ekerå was about 20 million qubits running for eight hours. That’s roughly a 20x drop in qubit count in six years.
  • March 2026, elliptic curves: a Google Quantum AI led paper by Babbush, Gidney, Boneh and others estimated that a 256-bit elliptic curve key (the curve Bitcoin uses) could be broken with no more than about 1,200 to 1,450 logical qubits, using under 500,000 physical qubits on superconducting hardware, in minutes. The authors validated the circuit with a zero-knowledge proof rather than publishing the attack itself.
  • March 2026, neutral atoms: Cain, Preskill, Bluvstein and colleagues estimated that reconfigurable neutral atom hardware could run Shor with as few as 10,000 atoms. Their more detailed figures are about 26,000 atoms for ECC-256 in roughly 10 days, and about 102,000 atoms for RSA-2048 in roughly 97 days.

Now the other half of the picture. The same neutral atom paper notes that today’s quantum processors operate with at most a few hundred physical qubits, and that “substantial engineering challenges remain.” Even the most optimistic design above is about two orders of magnitude bigger than what anyone runs today, and the superconducting estimates are more than a thousand times bigger. Those gaps are shrinking, but they are not small, and every one of these estimates assumes error rates and control systems that haven’t been demonstrated at that scale yet.

So when is Q-Day?

Nobody knows, and anyone who gives you a single date is selling something. The better forecasts give ranges.

  • The Global Risk Institute and evolutionQ Quantum Threat Timeline Report 2025, which surveys 26 quantum experts, puts the chance of a machine that can break RSA-2048 within 24 hours at about 28% to 49% within 10 years, and 51% to 70% within 15 years. The near term odds are much lower.
  • Security vendor Keyfactor (July 2026) cites a McKinsey survey in which 72% of experts expect a cryptographically relevant quantum computer by 2035. Keep in mind that a PQC vendor has a commercial interest in urgency.
  • In the Guardian’s coverage of Google’s 2029 announcement (March 26, 2026), Leonie Mueck, formerly of quantum startup Riverlane, noted that most timelines range from the 2030s to the 2050s.

That spread is the honest answer. A meaningful probability within ten years is enough to justify planning. It isn’t enough to justify panic.

Harvest now, decrypt later is the part that’s real today

Here’s the piece of the quantum story I’d never wave away. An attacker doesn’t need a quantum computer today to cause a quantum problem later. They can record encrypted traffic now and store it until the machine exists. That’s called harvest now, decrypt later, and NIST calls it one of the main reasons the transition is urgent.

Whether it matters to you depends on how long your secrets need to stay secret. A session cookie that expires tonight isn’t worth harvesting. Medical records, legal files, trade secrets, government data and long-lived credentials might be. If data needs to stay confidential for 10 or 15 years, the forecasts above already overlap with its lifetime.

Signatures are a different timing problem. A forged signature only matters once someone can forge it, so signature migration has to finish before a capable machine exists, not after. That’s why Google said on March 25, 2026 that it had reprioritized its own migration toward authentication and digital signatures.

Post-quantum cryptography: the migration clock

The good news is that the replacements exist and the standards are done. The hard part, as usual, is everything around them.

  • August 13, 2024: NIST published its first three post-quantum standards: FIPS 203 (ML-KEM, for key establishment), FIPS 204 (ML-DSA, for signatures) and FIPS 205 (SLH-DSA, a hash-based signature backup).
  • March 2025: NIST selected HQC as a backup key establishment algorithm built on different math from ML-KEM.
  • June 22, 2026: Executive Order 14412 requires federal high-value assets and high-impact systems to move to post-quantum key establishment by the end of 2030 and post-quantum signatures by the end of 2031.
  • October 27, 2026: NIST finalized NIST IR 8547, its transition road map. It supports both the 2035 federal target set by National Security Memorandum 10 and the faster Executive Order dates for the highest value systems, and it accommodates hybrid deployments that combine classical and post-quantum algorithms.
  • Europe: the EU’s coordinated road map, as summarized by Keyfactor, asks member states to start by the end of 2026, migrate high-risk systems by the end of 2030 and finish as far as practicable by 2035.
  • Industry: Google set a 2029 target for its own migration.

Even the people building quantum attacks treat these dates as prudent planning, not a prediction. In his 2025 paper, Gidney wrote that he agrees with deprecating vulnerable systems after 2030 and disallowing them after 2035, adding: “Not because I expect sufficiently large quantum computers to exist by 2030.”

Migrations simply take a long time. Anyone who has watched telephony move from TDM to SIP knows how long the tail of a protocol migration gets. The same will be true here, and it’s worst in places full of long-lived gear. Industrial and OT environments run devices for decades, which is one more reason the segmentation work I described in IT/OT Network Segmentation with the Purdue Model and IEC 62443 matters. You can’t upgrade the crypto on a box you can’t patch, but you can limit who can reach it. Matthew Green put it bluntly to Scientific American: “The upgrade process itself is going to be a bit of a catastrophe.”

Can AI crack the math?

This is where 2026 got genuinely interesting, so I want to be careful in both directions.

On the “take it seriously” side, AI is now doing real cryptanalysis research:

  • July 28, 2026: Anthropic reported that its Claude Mythos Preview model reduced the cost of key recovery against HAWK-256, a candidate in NIST’s additional signature competition, from about 264 operations to about 238, in roughly 60 hours and about $100,000 in API usage. It also found a faster theoretical attack on 7-round AES-128, which still needs 2105 chosen plaintexts and is completely impractical.
  • July 2026: CryptanalysisBench, a benchmark from researchers at ETH Zurich, Anthropic, the University of Haifa, TU Berlin and Tel Aviv University, tested frontier models on 191 tasks. The best models broke 65% to 86% of schemes that already had known practical breaks, and found a couple of genuinely new attacks on obscure, never-deployed competition candidates.
  • October 15, 2026: Scientific American reported that Matthew Green of Johns Hopkins put about a 15% chance on losing confidence in our existing public-key algorithms, in the context of AI-assisted cryptanalysis.

On the “bring the temperature down” side, read the fine print. Anthropic itself wrote that “neither of these results has a practical impact on today’s computer systems; no production software will have to change.” HAWK isn’t deployed. Reduced-round AES isn’t AES. In the CryptanalysisBench results, the hardest production ciphers held, and most full-strength wins came from bugs in reference code rather than flaws in the designs. And in the Scientific American piece, Govind Pimpale of the Foundation for American Innovation summed it up: “Today no currently deployed algorithm has been broken by AI.” Belgian cryptographer Bart Preneel said there’s “no real reason to panic.”

There’s a useful history lesson here too. Classical algorithms have chipped away at RSA for decades, which is why 512-bit keys fell and 2,048 bits became the floor. Cryptography absorbs better attacks by raising margins and moving on. That’s what’s happening with AI. It’s a new and fast-moving input to cryptanalysis, and it makes the case for crypto agility stronger. It isn’t evidence that the math is about to collapse.

One more nuance. AI’s clearest cryptographic wins so far have been around implementations, not designs. PostQuantum.com points to a 2023 deep learning side-channel attack against an implementation of Kyber, the algorithm that became ML-KEM. It worked by reading physical leakage from the device running the code, not by breaking the underlying math. The pattern matters, because it leads to the real problem.

Where AI actually bites: the code

Eyal Ronen of Tel Aviv University made the point in Scientific American that AI is already very good at finding software vulnerabilities, and that attackers usually take the easier route of stealing keys rather than breaking ciphers. The record over the last two years backs that up, and the trend line is steep:

  • April 2024: Fang, Bindu, Gupta and Kang showed a GPT-4 agent of only 91 lines of code could exploit 87% of 15 real one-day vulnerabilities when given the CVE description, at an estimated $8.80 per exploit. Several were WordPress plugin bugs. Without the description, success fell to 7%. Finding bugs was still the hard part.
  • November 1, 2024: Google’s Big Sleep agent found an exploitable memory-safety bug in SQLite before it reached an official release, which Google called the first public example of an AI agent finding a previously unknown exploitable bug of that kind in widely used software.
  • August 2025: In DARPA’s AI Cyber Challenge final, autonomous systems found 54 of 63 planted vulnerabilities across 54 million lines of code, patched 43 of them, and found 18 real vulnerabilities nobody had planted, at an average of about $152 per task.
  • October 21, 2026: Wiz disclosed PHP2Shell, a pair of memory-safety flaws in the PHP interpreter itself (CVE-2026-109618 and CVE-2026-109619) that allow unauthenticated remote code execution, demonstrated against WordPress, Drupal and Joomla. Wiz says the work was done with AI models, and that “a single researcher completed in a week what previously would have taken a world-class team months.” Wiz notes PHP runs about 70% of websites.
  • October 26, 2026: CISA added both CVEs to its Known Exploited Vulnerabilities catalog, five days after public disclosure, and urged patching to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Notice what’s on that list. Nobody broke AES. Nobody factored RSA. They found mistakes in code, and they found them faster and cheaper than before. For what it’s worth, this site runs on WordPress, which runs on PHP. This isn’t an abstract category of risk.

My take: hacking is a procedure, and AI runs procedures fast

This section is my opinion.

I personally land on the side that AI and quantum computing probably aren’t the existential threat to classical encryption that a lot of coverage suggests. The math has decades of scrutiny behind it, the replacement algorithms are standardized, and the breaks that make headlines keep turning out to be reduced versions, research candidates or implementations.

Hacking is different. Most of it isn’t genius. It’s a procedure. You enumerate what’s exposed, you check versions, you run through a big list of known weaknesses and techniques, you try the next thing, and you keep going until something gives. That’s exactly the kind of work AI agents are good at: a long checklist, run tirelessly, in parallel, at machine speed. I wrote about agents doing procedural work on the defensive side in AI Agents and Network Engineering, and the same property cuts both ways. It’s also related to what I described in AI Reverse Engineering and Software Cloning: reading and reasoning about code at scale is now cheap.

That’s why I think the real risk is the shrinking lead time to a working exploit. When the time from “a bug exists” to “someone has weaponized it” drops from months to days, the patch window becomes the security boundary. The PHP2Shell timeline is a good illustration: AI-assisted discovery in about a week, and active exploitation confirmed by CISA five days after disclosure.

To be fair to the other side, the same tools help defenders. Big Sleep found its bug before release. AIxCC systems wrote patches, not just exploits. Whether AI ends up favoring attackers or defenders depends heavily on how fast organizations can absorb fixes, and that’s an operations problem more than a cryptography problem.

Why the hype matters

Also my opinion, with a couple of examples.

Precision in how we talk about this matters, because the framing travels faster than the fine print. When Google set a 2029 deadline for its own post-quantum migration in March 2026, the headlines read “Google warns quantum computers could hack encrypted systems by 2029” (the Guardian) and “Google bumps up Q Day deadline to 2029” (Ars Technica). A migration target became, in many readers’ minds, a predicted break date. To their credit, both articles carried more nuance than their headlines did.

Markets react to this stuff. After the June 22, 2026 executive orders on quantum computing and post-quantum security, Benzinga reported after-hours gains across quantum-related stocks of roughly 2% to 13%, with D-Wave up about 7% and Infleqtion about 13%. Some of that is rational. Policy and funding matter. But it shows how quickly quantum headlines turn into price moves, and how easily fear about encryption can be priced into stocks, crypto assets and security budgets.

Even the WSJ’s August 25, 2026 explainer, “Why Quantum Computing Is a Threat to Cybersecurity”, opens by saying the math behind standard encryption “will be no match for quantum computers.” That’s true for RSA and ECC on a big enough machine. It’s not true for AES, and it says nothing about when. Those distinctions are exactly what gets lost when a story moves from a research paper to a headline to a trading screen.

What to actually do about it

The useful response isn’t fear. It’s a plan, and most of it is boring.

  • Inventory your cryptography. Know where RSA and ECC live: TLS endpoints, VPNs, SSH, code signing, PKI, firmware, and vendor appliances. You can’t migrate what you can’t find.
  • Prioritize by data lifetime. Data that must stay secret for a decade or more is the harvest now, decrypt later target. Move key exchange for that traffic first.
  • Turn on hybrid key exchange where it’s available. Hybrid schemes that pair a classical algorithm with ML-KEM, which NIST IR 8547 accommodates, protect you if either one holds. This is already showing up in TLS; Google, for example, points to PQC support in Chrome.
  • Build crypto agility. Favor systems where algorithms can be swapped by configuration, not by a forklift upgrade. That’s the real defense against both quantum and AI-assisted cryptanalysis.
  • Ask your vendors for dates. Your PQC timeline is only as good as the slowest box in your network.
  • Don’t panic-buy. AES-128 and SHA-256 don’t need emergency replacement. Be skeptical of products sold on fear.
  • Shrink your patch window. This is the one that pays off today. Know your internet-facing software, track the KEV catalog, and treat critical patches as hours-to-days work, not a monthly ritual.

The bottom line

Quantum computing is a real, specific threat to public-key cryptography, and the harvest now, decrypt later risk means some data is exposed to it already. The fix is known, standardized and on a published schedule. AI is getting better at cryptanalysis, and that deserves watching, but no deployed algorithm has fallen to it.

The threat that’s here right now is less glamorous. AI makes finding and exploiting ordinary software bugs faster and cheaper, and the window between disclosure and exploitation is shrinking. If you’re deciding where to spend your next hour of security effort, my vote is: start your post-quantum cryptography inventory, then go patch your web stack.

Sources

Found this useful?

Everything here is free and stays that way. If something I wrote saved you a headache, you can support the site on Ko-fi.

Support on Ko-fi

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *

Latest Comments

No comments to show.