AI and cryptography, explained.
AI is not quietly breaking AES-256. Here's what it actually threatens, what a much older problem — bad randomness — still threatens, and why quantum computers, not AI, are driving cryptography's next generation.
"AI is breaking encryption" is one of the most durable pieces of security folklore going, and it's worth being precise about exactly how wrong it is. Modern encryption — AES-256, RSA-2048 and larger, elliptic-curve schemes — rests on mathematical problems that remain computationally infeasible to solve directly, and there is no credible published research showing machine learning changing that. Nothing about training a neural network gives it a shortcut through the underlying math.
What's actually true is narrower, and more interesting: AI genuinely helps attackers against weak implementations and side channels, a well-documented random-number problem has broken far more real systems than any AI ever has, and a wholly different technology — quantum computing, not AI — is what's actually driving the biggest change happening in cryptography right now. Keeping those three threads separate is the entire point of this article, and conflating them is exactly how hype crowds out the real risk.
What AI-assisted cryptanalysis actually is
Cryptanalysis is the study of finding weaknesses in cryptographic systems, and it's a decades-old academic field with plenty of purely mathematical successes long before machine learning entered the picture. Applying AI to it is a genuinely active area of current research — the important part is understanding precisely what it's aimed at.
The strongest, best-established results are in side-channel analysis: attacks that don't touch the mathematical algorithm at all, but instead extract information a physical device leaks while it computes — variations in power consumption, electromagnetic emissions, or execution timing that correlate with the secret key material being processed. Classical side-channel analysis already worked without AI, most notably against smart cards and embedded devices, but it required a skilled analyst to hand-pick the statistical features to look for. Neural networks have been shown, in published academic research, to automate and often improve on that process — learning which patterns in a power trace correlate with key bits directly from data, without a human specifying the features in advance. This is a real, meaningful capability. It is also, specifically, an attack on an implementation — a chip, a device, a piece of code that leaks information it shouldn't — not an attack on the strength of the algorithm's underlying math.
A second, smaller body of research applies machine learning to reduced-round or non-standard, often lightweight, cipher constructions — deliberately weakened or simplified versions of ciphers used to study how attacks might scale, or genuinely under-designed algorithms found in some low-power or proprietary systems. Results here are real but narrow: they tend to apply to specific, already-weakened, or non-standard constructions, not to full-strength, well-vetted standards like AES-256 run at full rounds.
Put together, the accurate framing is that AI is a force multiplier against flawed implementations and leaky hardware, not a shortcut through hard mathematical problems. An organization using well-implemented AES-256 or RSA-2048 correctly is not meaningfully more at risk today because of AI cryptanalysis research. An organization running cryptography on a device that leaks power-consumption data to anyone nearby, or that implemented its own custom cipher instead of a vetted standard, has real reason for concern — and had that reason before AI made the attack easier to automate.
The much older, much bigger risk: weak randomness
Long before AI cryptanalysis was a research topic, the single most common way real cryptographic systems actually failed had nothing to do with the algorithm at all: predictable or insufficient randomness during key generation. Every standard encryption algorithm assumes its keys were drawn from a source indistinguishable from true randomness. Feed a cryptographically secure algorithm a predictable key, and the algorithm's theoretical strength becomes irrelevant — an attacker doesn't need to break AES-256 if they can simply guess or reproduce the key that was generated.
This is not a hypothetical concern. A well-documented real-world example: in 2008, a code change made two years earlier to Debian's OpenSSL package was found to have severely reduced the entropy used by its pseudorandom number generator when creating SSH and TLS keys. The flaw was serious enough that essentially every key generated by an affected system during that window had to be treated as guessable and regenerated — a strong, standard algorithm, undermined entirely by the randomness feeding it, affecting a huge number of real keys in production use.
The practical lesson holds regardless of AI: entropy sources — hardware random number generators, OS-level entropy pools, proper seeding on embedded and IoT devices at first boot — are foundational, unglamorous infrastructure, and a poorly implemented one is a far easier, far more common route to compromising a system than any cryptanalytic breakthrough, AI-assisted or otherwise. When evaluating cryptographic risk, "how is randomness generated here" deserves at least as much scrutiny as "which algorithm was chosen."
The real "break the math" threat: quantum computers, not AI
If there's a technology that genuinely threatens to break the mathematical assumptions behind widely deployed public-key cryptography, it's quantum computing — and it's worth being explicit that this is a separate threat model from AI entirely. A sufficiently large, sufficiently error-corrected quantum computer running Shor's algorithm could, in principle, efficiently solve the integer-factorization and discrete-logarithm problems that RSA and elliptic-curve cryptography depend on — something no classical computer, and no AI model running on classical hardware, can currently do. No quantum computer built to date has anywhere near the scale or error correction needed to run that attack against real-world key sizes, but the field has been moving fast enough, and the stakes are large enough, that standards bodies have already acted.
In August 2024, NIST finalized its first post-quantum cryptography standards, the culmination of a multi-year public evaluation process:
| Standard | Purpose | Based on |
|---|---|---|
| FIPS 203 — ML-KEM | Key encapsulation (establishing a shared secret, the post-quantum analogue of what RSA or Diffie-Hellman key exchange do today) | CRYSTALS-Kyber |
| FIPS 204 — ML-DSA | Digital signatures | CRYSTALS-Dilithium |
| FIPS 205 — SLH-DSA | Digital signatures, hash-based alternative with a different security foundation than ML-DSA | SPHINCS+ |
These schemes rely on different underlying mathematical problems — largely lattice-based for ML-KEM and ML-DSA, hash-based for SLH-DSA — believed to resist both classical and quantum attacks, in place of the factoring and discrete-log problems Shor's algorithm targets.
The reason organizations are moving on this now, rather than waiting until a cryptographically relevant quantum computer actually exists, is a pattern known as "harvest now, decrypt later." An adversary can capture and store encrypted traffic today — intercepted communications, stolen backups of encrypted archives — with no ability to read it yet, and simply wait. If a sufficiently powerful quantum computer arrives in ten or fifteen years, that stored traffic becomes readable retroactively. For data with a short shelf life, this barely matters. For data that needs to stay confidential for decades — government secrets, long-term health records, infrastructure design details — it means the migration to post-quantum algorithms has to start well before the quantum threat is imminent, which is exactly why government agencies, financial institutions, and critical-infrastructure operators are the ones currently leading early post-quantum migration planning.
For the underlying mechanics of how key exchange and digital signatures work today — the systems ML-KEM and ML-DSA are ultimately standing in for — see our companion pieces on cryptography basics and TLS certificates and Certificate Transparency, which cover the hashing, encryption, and signature primitives, and the certificate infrastructure built on top of them, that any future post-quantum transition still has to interoperate with.
What this means in practice
Translated into concrete priorities, the picture above suggests a fairly clear order of operations for anyone responsible for cryptographic risk in a real system, rather than a research lab:
- Audit entropy sources first. Confirm keys are generated using a proper CSPRNG with sufficient seeded entropy, especially on embedded devices, IoT hardware, and anything that generates keys immediately at first boot, when entropy pools are often thinnest.
- Use vetted, standard algorithms at full parameters. AES-256, RSA-2048 or larger, and standard elliptic-curve schemes remain the right default. Custom or reduced-round ciphers are exactly the category where both classical and AI-assisted cryptanalysis have shown real results.
- Treat physical and embedded devices as a side-channel surface. If a device performing cryptographic operations is physically reachable by an adversary, power-consumption and timing leakage are a real concern, and AI-assisted analysis has made that class of attack more accessible, not less.
- Start post-quantum planning by inventory, not panic. Identify which systems protect data with a long confidentiality horizon and which cryptographic libraries they depend on, so a future migration to ML-KEM and ML-DSA is a planned upgrade rather than an emergency response.
None of this requires assuming AI has already changed what's achievable against well-implemented modern cryptography — because for the algorithms themselves, it hasn't. It requires the same discipline cryptographic engineering has always demanded: get the randomness right, use the standard algorithm correctly, and plan the next transition before you're forced into it.
Keeping the three threats straight
The single most useful thing a reader can take from this topic is a habit of separating three distinct claims that get blurred together constantly in casual coverage:
- AI cryptanalysis is real, active research — and it targets implementations and side channels, not the strength of well-vetted algorithms at full parameters.
- Weak randomness is an older, better-documented, and in practice far more common way real cryptographic systems actually fail, entirely independent of AI.
- Quantum computing is the one technology that could genuinely break the math behind RSA and elliptic-curve cryptography — which is precisely why the transition to post-quantum standards is already underway, years before the quantum threat is expected to be practical.
Confusing these three does real harm: it either produces unwarranted panic about AI capabilities that don't exist yet, or it produces complacency about the far more mundane risks — a bad entropy source, an unvetted custom cipher, a leaky hardware implementation — that are quietly breaking real systems today.