Claude has started reviewing cryptography.

Claude Turns Its Hand to Cryptographic Auditing

Anthropic recently disclosed new security research showing that Claude can now help researchers analyze cryptographic code, identify potential weaknesses, and verify whether those issues genuinely exist.

This deserves more attention than simply saying, “AI can find vulnerabilities again.”

SQL injection, path traversal, and unauthorized access can usually be traced through inputs and data flows. Cryptographic flaws, by contrast, are often hidden in protocol assumptions, state machines, random number generation, key lifecycles, and constant-time implementations. Every line of code may be valid, and all unit tests may pass, yet the system can still be insecure when everything is put together.

The focus of Anthropic’s demonstration is not that Claude can break AES, RSA, or elliptic-curve cryptography out of thin air. Rather, it is beginning to develop a more practical capability: reading implementations of cryptographic systems, understanding the security invariants their designers intended to preserve, and then finding the gaps between the code and the design.

This is also the most realistic role for large language models in security today. They may not replace cryptographers, but they can turn what was once expensive and scarce expert review into a highly parallelized triage and validation process.

What It Usually Finds Is Not a “Broken Algorithm,” but a Misused One

When discussing AI and cryptography, the most common misconception is whether Claude can already break modern cryptographic algorithms.

The answer is essentially no, and that is not what Anthropic demonstrated.

Cryptographic primitives that have been thoroughly studied and publicly scrutinized rarely become invalid simply because a model has read a few papers. The more common problem in production systems is that developers choose the right algorithm but use it in the wrong context. Typical weaknesses include:

• Reuse of nonces, IVs, or ephemeral keys;
• Predictable random number sources or insufficient entropy;
• Encryption without authentication, allowing attackers to tamper with ciphertext;
• Signature verification that omits critical fields, allowing the context to be substituted;
• Reusing the same key across different protocols without domain separation;
• Leaking timing information when comparing MACs, signatures, or tokens;
• Returning different errors along failure paths, creating an observable decryption oracle;
• Retaining weak algorithms for legacy compatibility and accidentally selecting them through algorithm negotiation;
• Writing keys to logs, caches, crash dumps, or leaving them resident in memory for extended periods;
• Inconsistent serialization and parsing rules that make signed objects ambiguous.

What these problems have in common is that they often span multiple functions, files, or even services. Traditional static scanners are good at matching dangerous APIs, but they may not recognize that a random value is reused after passing through three layers of abstraction. They also struggle to determine whether a field omitted from a signature can alter the meaning of a transaction.

This is precisely where Claude has an advantage. A large language model can first translate code into a natural-language explanation, then work backward by asking: What security assumptions does the system rely on? What can the attacker control? Which fields must be bound together? Which secrets must remain unobservable?

It is more like an extremely fast-reading audit assistant that keeps asking questions than a linter limited to checking a rule table.

Why Cryptographic Auditing Is Harder Than Ordinary Code Review

Ordinary business logic is often evaluated by asking whether the result is correct. Cryptographic code must answer another question as well: Does the computation leak information that should remain secret?

For example, the following comparison is functionally correct:

function verify(expected, provided):
    if length(expected) != length(provided):
        return false

    for i in range(length(expected)):
        if expected[i] != provided[i]:
            return false

    return true

However, it returns early when it encounters the first differing byte. If an attacker can make repeated requests and precisely measure response times, they may be able to infer the correct value one byte at a time. In a real project, developers should not attempt to “patch” this loop themselves. They should use a reviewed constant-time comparison function and confirm that the compiler, runtime, and deployment environment do not undermine its guarantees.

This kind of problem cannot be detected by looking only at a function’s output. The model must simultaneously understand:

1. Whether the compared data is secret;
2. Whether an attacker can control the input and take repeated measurements;
3. Whether the timing difference can be distinguished through network noise;
4. Whether the language runtime provides reliable constant-time primitives;
5. Whether the fix introduces length leakage or differences in exception paths.

In other words, a cryptographic vulnerability is not merely a code pattern. It exists at the intersection of code, environment, and threat model.

What Anthropic’s research genuinely advances is Claude’s participation in this cycle of “assumption—counterexample—validation.” The model first raises a suspicion, then reduces false positives by running tests, reading adjacent modules, constructing a minimal reproduction, or checking the protocol specification. For human researchers, this can eliminate a large amount of mechanical work. For the model, external tools constrain its tendency to hallucinate answers based solely on language generation.

What Claude Is and Is Not Suited For

From a developer’s perspective, this capability is best suited to three stages.

First, Building a Map of the System’s Cryptographic Assets

Many teams cannot even clearly state how many cryptographic schemes are used in their codebases. Cryptographic operations may be scattered across authentication services, mobile clients, database SDKs, message queues, and legacy compatibility layers.

Claude can begin by answering a set of basic but time-consuming questions:

• Which modules generate, store, derive, or transmit keys;
• Which external inputs ultimately enter signing and verification flows;
• Which services implement their own wrappers around standard cryptographic libraries;
• Whether duplicate implementations, legacy protocols, or conditional downgrade paths exist;
• Which callers would be affected by a key rotation.

This step may not directly uncover critical vulnerabilities, but it can significantly narrow the scope of manual auditing.

Second, Turning “Suspicious Code” Into a Testable Hypothesis

Traditional scanners usually report that a dangerous function has been called. A better security audit must explain the conditions required for exploitation, the scope of impact, and the reproduction path.

For example, a model should not merely say, “The nonce here may be insecure.” It should continue tracing the nonce’s source, lifecycle, and uniqueness boundary, determining whether it is unique within a single process, unique under a single key, or unique across the entire cluster. If the value consists of a timestamp and a local counter, the analysis must also consider restarts, clock rollback, horizontal scaling, and state recovery.

Only when all these conditions have been fully examined does the finding deserve to enter the remediation queue.

Third, Assisting With Fixes and Regression Testing

A cryptographic fix cannot simply change the one line that triggers the vulnerability. Changing the serialization format may invalidate historical signatures, modifying key derivation may affect data migration, and disabling an old algorithm may cause widespread client disconnections.

Claude’s value lies in helping developers identify compatibility impacts, generate regression tests, and check whether similar patterns exist in other modules. However, the final patch must still be reviewed by someone familiar with the system’s threat model and, when necessary, by an independent cryptography expert.

The tasks for which it is unsuitable are equally clear: proving a new cryptographic primitive secure, replacing formal verification, confirming solely from source code that a microarchitectural side channel has been eliminated, or reaching definitive conclusions without information about the actual deployment.

Being able to explain a risk does not mean the risk has been proven; being able to generate a patch does not mean the patch provides cryptographic guarantees.

The Most Useful Question for Development Teams Is Not “Are There Any Vulnerabilities?”

Dumping an entire repository into a model and asking it to “find cryptographic vulnerabilities” will usually produce only a long and generic checklist. A more effective approach is to have the model work from a clearly defined threat model.

An audit task template like the following can be used:

Objective: Review the token issuance and verification flow

Attacker capabilities:
- Can register an ordinary account
- Can control request parameters and token contents
- Can repeatedly send requests and observe status codes, response bodies, and latency
- Cannot read server-side keys

Invariants that must be preserved:
- The token’s user, permissions, audience, and expiration must be bound by the signature
- Signing contexts must not be reused across environments or purposes
- Verification failures must not leak exploitable differences

Output requirements:
- Provide cross-file data flows
- List the prerequisites for each finding
- Distinguish confirmed issues, issues requiring experimental validation, and low-confidence hypotheses
- Provide a minimal reproduction approach and regression tests
- Do not design new cryptographic algorithms

The key to this template is not prompt engineering, but clearly defining the security boundary. The better the model understands what an attacker can do and what the system must guarantee, the less likely it is to misreport something that is “theoretically imperfect” as “practically exploitable.”

It is also inadvisable to use model conclusions directly as blocking conditions in CI. A more robust process is:

1. Use deterministic tools to scan dependencies, leaked keys, and known dangerous APIs;
2. Have Claude inspect cross-file semantics, protocol binding, and exception paths;
3. Require the model to generate reproducible evidence for high-risk findings;
4. Have security engineers confirm the attack conditions and business impact;
5. After remediation, add deterministic unit, property-based, or fuzz tests;
6. Use specialized measurement tools for side-channel issues rather than asking the model to draw conclusions from the appearance of the code.

This division of labor is far more reliable than “fully automated AI auditing.” The model expands the search space, while humans and tools narrow down the evidence.

How Does This Relate to Claude Security?

In May this year, Anthropic expanded the public beta of Claude Security, which performs parallel scanning, cross-file data-flow analysis, and multi-stage validation on enterprise codebases, while connecting findings to the Claude Code remediation workflow. Its coverage already includes cryptographic issues such as algorithm confusion, weak cryptographic primitives, and timing leaks.

This cryptography research can be seen as a further clarification of the capability boundary rather than a separate new model release. The research addresses whether the model can participate in more specialized cryptographic discoveries, while Claude Security packages code scanning, findings management, and remediation workflows into an enterprise product.

The two should not be conflated. Research demonstrations often allow researchers to repeatedly guide the model, provide tools, and add context. Enterprise scanning, however, must contend with millions of lines of code, incomplete documentation, complex build environments, and strict false-positive budgets. There remains an engineering gulf between finding issues in an experiment and finding them reliably in production repositories.

The Real Bottleneck Will Shift From Finding Vulnerabilities to Handling Them

If models continue to improve, the next problem security teams face may not be “we cannot find vulnerabilities,” but “we cannot fix them all.”

A model can read dozens of repositories in parallel, but key migrations, protocol upgrades, and client compatibility changes still require engineering teams to handle them one by one. This is especially true for cryptographic issues: remediation often involves re-encrypting data, updating certificates, rotating keys, and gradually rolling out changes across multiple versions. It cannot be completed simply by merging a single pull request, as is often possible with an ordinary dependency upgrade.

This will lead to two immediate changes.

First, the quality threshold for vulnerability reports will rise. AI-generated reports without attack paths, confidence levels, or impact analyses merely create another backlog. Security products must prove that they reduce the cost of human validation, not merely increase the number of findings.

Second, asset ownership and remediation responsibility will become more important than scanning capability. Teams need to know who manages each key, who maintains each protocol, and when legacy clients will be retired. Otherwise, no matter how many issues AI finds, they will simply end up on an unclaimed list.

Assessment: It Is Not a Replacement for Cryptographers, but It Is Already Useful Enough

The most important implication of Claude’s ability to help identify cryptographic weaknesses is not that the model has acquired some mysterious “code-breaking capability.” It is that highly specialized security knowledge is beginning to be embedded in everyday development workflows.

For mature security teams, it is a search-space multiplier: it can quickly map code, challenge design assumptions, generate tests, and help experts reserve their time for the hardest judgments. For teams without dedicated cryptography specialists, it can at least expose obvious risks involving nonces, key management, protocol binding, and side channels earlier.

But the boundaries must also be made clear. In cryptography, few things are more dangerous than something that merely “looks reasonable,” and language models happen to excel at generating explanations that look reasonable. Every high-risk conclusion requires reproducible evidence, and every fix should prioritize established standards and audited libraries rather than accepting a new protocol improvised by the model.

The right approach, therefore, is not to have Claude stamp a system as “cryptographically secure,” but to integrate it into the audit pipeline: let it ask more good questions, then use testing, measurement, formal tools, and human experts to provide the final answers.

That is already enough to transform secure development workflows, but it remains a long way from automatically proving software secure.

References

• iThome: Anthropic Makes Claude Security Available to Enterprises for Vulnerability Scanning — An overview of Claude Security’s public beta, cross-file scanning, multi-stage validation, coverage of cryptographic vulnerabilities, and remediation workflow.