AI Is Accelerating Cryptanalysis. Cryptography Must Learn to Adapt 

In July 2026, Anthropic reported two cryptanalysis results produced with Claude Mythos Preview. One improved an attack against HAWK, a proposed post-quantum signature scheme. The other improved an attack against a seven-round version of AES. Anthropic was explicit about the limits: neither result affects production systems today. 

That caveat is the right place to begin. AI has not suddenly made deployed encryption useless. It has changed how quickly researchers can search a large body of techniques, test hypotheses, write experiments, and explore unfamiliar constructions. The immediate effect is an acceleration of cryptanalytic work, not a magical shortcut through hard mathematics. 

The practical question is therefore not whether AI will “break cryptography.” It is which parts of a cryptographic system are under pressure, what recent results actually demonstrate, and whether defenders can respond before a research finding becomes an operational incident. 

Three ways a cryptographic system can fail  

Cryptographic security has at least three layers, and they should not be treated as interchangeable. 

The first is the construction: the algorithm, its parameters, and the mathematical assumptions behind it. A public encryption algorithm is expected to be examined by everyone. Its security depends on an attacker being unable to solve the relevant problem with available resources. A digital signature scheme must let anyone verify a signature without making forgery feasible. Security proofs make those claims precise, but only under stated assumptions and for a specified security goal. 

The second is the implementation. A mathematically sound algorithm can leak through timing, cache behaviour, power consumption, electromagnetic emissions, unsafe randomness, or fault responses. An implementation can also misuse a correct primitive or expose a secret through an ordinary programming error. None of these attacks needs to defeat the underlying mathematical problem. 

The third is operation. Keys need to be rotated. Compromised clients need to be revoked. Protocols need a path to new algorithms. Security teams need to know where cryptography is used and which data depends on each key. A system that cannot change after a weakness is found has less practical resilience than its algorithm name suggests. 

This separation also explains why the recent AI results should not be summarized as one undifferentiated attack on encryption. HAWK concerns a candidate construction. The AES result concerns a reduced research target. The BSI examples concern implementation analysis. Each result has a different threat model and a different practical meaning. 

Cryptography sits inside a larger attack surface 

Cryptography rarely fails in isolation. The deployment around a primitive affects how an attacker observes, tests, and responds to it. 

A 2026 study by Petar Radanliev reaches a related conclusion from a different direction. Its methodology combines bibliometric analysis with twenty expert interviews and three industry workshops to examine AI-driven attacks against public-key systems. The paper argues that cryptographic security should be treated as an adaptive, system-level property rather than as a function of algorithm strength alone. Its interview and workshop evidence is useful as a signal about practitioner concerns, but the small qualitative sample should not be read as a population-wide prevalence estimate. 

That system-level framing is useful here because it connects the construction, implementation, and operational layers. AI can search for weaknesses in a scheme, help analyze leakage from an implementation, and make activity after a compromise more adaptable. These are different capabilities, but they all reward systems that can be inspected, verified, and changed. 

The same acceleration can make application impersonation cheaper, including in systems that use public-key cryptography. Applications may carry a public key or certificate as part of their normal operation, for example to identify a signing authority or verify signed messages. That material is meant to be public, but it can still become an impersonation artifact. Malware can extract it and copy it into a lookalike application when a backend or security check treats presentation of a particular key or certificate as proof of application identity. AI-assisted malware could automate that extraction, reconstruct request flows, generate the lookalike client, and adapt its traffic as the application changes. 

Extracted public material still cannot forge the corresponding signatures or decrypt data. The weakness is that the surrounding protocol has confused public cryptographic material with proof that a request came from the genuine application. Where client identity matters, the server needs a stronger signal, such as platform attestation where available or a signature proving possession of a private key generated and protected on that installation. AI accelerates extraction and construction of the impersonating client; it does not break the public-key algorithm underneath it. 

What the recent results demonstrate 

HAWK: an important result against a candidate 

Anthropic reported an improved key-recovery attack against HAWK, a proposed post-quantum signature scheme based on the Lattice Isomorphism Problem. HAWK had advanced through rounds of NIST’s process for additional post-quantum signature schemes, but it was not a deployed or standards-adopted algorithm. The HAWK project now records that the scheme was withdrawn from the process after the attack was disclosed. 

The result is still significant. Anthropic says the attack effectively cuts HAWK’s key strength in half. The attack remains exponential rather than becoming a practical polynomial-time break, and larger parameter sets remain difficult to attack. But restoring the intended security margin would require changes that undermine some of HAWK’s efficiency advantages. 

This is a construction-level finding, not a verdict on post-quantum cryptography as a whole. The attack is specific to HAWK. It does not transfer directly to Falcon, which is based on a different hard problem, and it does not show that lattice-based cryptography in general is broken. The value of the result is precisely that public review found a weakness before HAWK became a standard used in deployed systems. 

Reduced-round AES: a research advance, not a practical break 

The second Anthropic result concerns a seven-round version of AES-128. Full AES-128 uses ten rounds; AES-192 and AES-256 use twelve and fourteen rounds. Cryptanalysts study reduced-round versions because they provide a way to test attack techniques and estimate security margins without having to defeat the full cipher. 

Anthropic reports a new meet-in-the-middle technique that improves previous attacks on seven-round AES by roughly 200 to 800 times, depending on how the runtime is measured. The attack still assumes a chosen-plaintext setting, in which an attacker can request encryptions of many inputs under a fixed unknown key. The prior work requires about 2105 chosen plaintexts, making the experiment completely impractical against ordinary systems. 

This is useful evidence that AI can contribute to cryptanalytic research. It is not evidence that HTTPS, disk encryption, or other systems using full-round AES need an emergency migration. A result against seven rounds cannot be presented as a break of ten-round AES without erasing the condition that makes the result meaningful. 

CryptanalysisBench: measuring capability more systematically 

A benchmark is not an attack on deployed cryptography, but it can show whether models are becoming useful at the work that leads to attacks. CryptanalysisBench evaluates language models across 191 tasks covering six families of cryptographic primitives. 

The paper separates tasks into three broad groups: schemes with known practical breaks; schemes with no known practical break, tested at full strength and in scaled-down variants; and challenge tasks intended to represent the frontier of cryptanalysis. In its reported results, frontier models solve a large share of the tasks with known breaks, solve several full-strength tasks in the second group, and solve many more scaled-down variants. 

The authors also report a key-recovery attack involving a design flaw in the SpoC authenticated-encryption construction and an error in KINDI’s published chosen-ciphertext-security proof. Those findings should be attributed carefully: the paper presents them as novel to the authors’ knowledge, not as a reason to assume that every similar construction is unsafe. Their importance is that model output can now produce concrete claims that researchers can test against real specifications and implementations. 

The benchmark’s operational value is therefore twofold. It gives researchers a way to measure progress, and it offers a possible pre-deployment stress test for candidate schemes. It does not remove the need for expert review. A model can produce a persuasive argument that targets a weaker variant, misstates an assumption, or contains a subtle error. The cheaper discovery becomes, the more valuable independent verification becomes. 

AI already matters at the implementation layer 

The connection between AI and cryptography is not limited to large language models. The German Federal Office for Information Security (BSI) describes machine learning as an established technique in side-channel analysis. A side-channel attack learns from effects that computation unintentionally produces, such as runtime, power consumption, electromagnetic emissions, or cache behavior. 

The BSI reports that its team combined a neural network with a SAT solver to recover an AES secret key from power-consumption curves in the CHES Challenge 2018. In the 2020 challenge, the team applied related techniques to Clyde-128, a lightweight cipher implementation designed to resist side-channel attacks. These examples do not break AES as a mathematical construction. They recover information leaked by a physical implementation. 

This distinction matters for defenders. AI can help an attacker process noisy measurements, select useful features, compare hypotheses, and connect statistical recognition to exact key recovery. It can also help defenders find leakage during testing. The BSI is studying how these methods apply to asymmetric and post-quantum implementations, while noting that the strongest results often combine machine learning with expert knowledge. 

The lesson is not that machine learning replaces cryptanalysis expertise. It is that implementation security is already a practical research area in which automation can lower the cost of specialized analysis. 

White-box cryptography is a cost raiser, not a trust boundary 

White-box cryptography is a useful case study because it makes the implementation problem unusually clear. Suppose an application must verify a license token or authenticate a client request. A conventional message-authentication code (MAC) relies on a secret key. If an untrusted client receives that key, an attacker who controls the client can potentially create valid MACs, regardless of whether the cryptographic algorithm is strong. 

White-box techniques try to make the embedded key harder to extract by combining it with obfuscated code, transformed lookup tables, and other implementation techniques. They are designed for software running in an environment the user can inspect and manipulate. That makes them useful for raising the cost of attacks against software-only payment components, licensing systems, content protection, and some on-device model-protection schemes. 

They do not turn the client into a trusted environment. In a 2016 Microsoft Research talk, the authors of Differential Computation Analysis described a software counterpart to differential power analysis. Their tooling recorded memory-access traces from instrumented software and used key-dependent correlations to extract keys from publicly available white-box implementations of standardized cryptography. The attack did not require access to the vendor’s lookup tables or a traditional reverse-engineering effort. 

DCA is not an AI result. AI may make parts of trace analysis faster, but that is a forward-looking possibility rather than something demonstrated by the DCA source itself. The established conclusion is already sufficient: obfuscating a computation does not remove the information that the computation produces. 

White-box cryptography can be a reasonable mitigation when trusted hardware is unavailable or cannot be used across a device population. It should not be treated as the sole protection for a high-value secret or transaction. Server-side authorization, hardware-backed keys where available, code signing, runtime integrity checks, monitoring, short-lived credentials, and a revocation path address different failure modes. The design should assume that the client may eventually be modified or extracted. 

What still provides a stronger position 

No algorithm comes with a permanent guarantee. A stronger position comes from combining several properties: 

– Publicly reviewed constructions at full strength. A finalized, widely analyzed standard with a meaningful security margin is a better starting point than a proprietary design or a reduced-round experiment. NIST’s ML-KEM and ML-DSA standards benefit from public analysis, but standardization does not make future review unnecessary. 

– Conservative assumptions and margins. A scheme should not depend on the best known attack being only slightly more expensive than the required security level. Candidate constructions need continued analysis even after they survive an initial review process. 

– Hardened implementations. Constant-time behavior, safe randomness, side-channel testing, fault resistance, secure key storage, and correct protocol composition protect the gap between a primitive and the device that runs it. The BSI guidance on side-channel resistance treats this as an engineering and evaluation problem, not a property that follows automatically from an algorithm’s name. 

– Do not treat public key material as proof of application identity. A public key or certificate extracted from an app can be copied into a lookalike client. Its presence may fool a weak identity check, but it cannot by itself create a valid signature. Where client identity matters, use platform attestation where available or a per-installation private key generated and protected on the device, require proof of possession, and support revocation. 

– Independent verification. Reproduce an attack, check its parameters, test its code, and review the theorem it actually proves. Formal and machine-checkable proofs can help, but experts still need to confirm that the formal statement matches the security claim that matters. 

– The ability to replace components. Inventory cryptographic dependencies, separate algorithm choices from application logic, version protocols, support an orderly migration path, rotate keys, and revoke compromised clients. This is crypto-agility in practical terms. 

For software on user-controlled devices, there is one more separation to maintain. Confidentiality, integrity, device trust, and authorization are different security goals. White-box techniques may help with one part of a design, but they cannot make all of those goals true at once. 

Resilience means being able to move 

AI-assisted cryptanalysis changes the tempo of security research. A candidate can be searched more deeply. A side-channel trace can be processed at greater scale. A possible attack can become executable code before a human team has finished reading the relevant literature. That makes verification, reproducibility, and expert judgment more important, not less.  

The immediate response is not to abandon established cryptography. It is to make the surrounding security program easier to inspect and change. Use public constructions with generous margins. Test real implementations for leakage. Treat model-generated findings as hypotheses until they are independently reproduced. Track where algorithms and keys are used. Rehearse migration before an emergency. 

Cryptography is not resilient because it is mysterious. It is resilient when its assumptions are public, its implementations are tested, its claims are verifiable, and its operators can replace a component when new evidence changes the picture. AI will keep improving the attacker’s toolkit. Defenders need systems that can improve and change at a comparable pace. 

Sources and further reading 

• “Anthropic: Discovering cryptographic weaknesses with Claude”: https://www.anthropic.com/research/discovering-cryptographic-weaknesses 

• “CryptanalysisBench: Can LLMs do Cryptanalysis?”: https://arxiv.org/abs/2607.18538 

• “Matthew Green: Some thoughts about Anthropic’s new cryptanalysis results”: https://blog.cryptographyengineering.com/2026/07/29/some-notes-about-anthropics-new-results/ 

• “BSI: Applications of Artificial Intelligence in Cryptography”: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kryptografie/KI-in-der-Kryptografie/ki-in-der-kryptografie.html 

• “BSI: Side-Channel Resistance”: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kryptografie/Seitenkanalresistenz/seitenkanalresistenz_node.html 

• “NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard”: https://csrc.nist.gov/pubs/fips/203/final 

• “NIST FIPS 204: Module-Lattice-Based Digital Signature Standard”: https://csrc.nist.gov/pubs/fips/204/final 

• “HAWK: A signature scheme inspired by the Lattice Isomorphism Problem”: https://hawk-sign.info/ 

• “Microsoft Research: Differential Computation Analysis”: https://www.microsoft.com/en-us/research/video/differential-computation-analysis-hiding-your-white-box-designs-is-not-enough/ 

• “Radanliev: AI-driven adaptive adversaries and the erosion of cryptographic trust in public key systems”: https://link.springer.com/article/10.1186/s40543-026-00547-y