DeepMind’s AI Agents Sharpen Two RSA-1024 Attacks | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
DeepMind’s AI Agents Sharpen Two RSA-1024 Attacks
Human-guided agents helped cut a completed computation’s CPU use by 3.5× and develop a theoretical batch-factoring method, while DeepMind says RSA-2048 and modern schemes are unaffected.
Google DeepMind announced on November 6, 2026, that AI agents working under human supervision contributed to two cryptanalytic advances against legacy 1024-bit RSA, while stating that RSA-2048 and modern cryptographic schemes remain unaffected.
The clearest result is a completed computation that used roughly 391 CPU-core-years, compared with 1,380 for an earlier run — a measured 3.5× reduction attributed to implementation improvements, not a new algorithm. A second paper proposes a theoretical batch-factoring construction called fan factories, with algebraic identities verified in Lean 4, but no end-to-end implementation at cryptographic scale.
Google DeepMind says AI agents working under human supervision contributed to two cryptanalytic advances involving legacy 1024-bit RSA. One working paper includes a completed signature-related computation that used about 391 CPU-core-years, compared with 1,380 CPU-core-years reported for an earlier run. The other proposes a new way to share computation across many factorization targets.
DeepMind says these results do not threaten RSA-2048, larger RSA keys or modern cryptographic schemes. They are also different kinds of evidence: a measured implementation improvement, a theoretical signature-attack improvement and a theoretical batch-factorization construction.
DeepMind research leader Pushmeet Kohli announced the work on November 6, 2026, describing the agents as “guided by human supervision.” His announcement identifies research led by Dj Dvijotham and Abhradeep Thakurta, with collaborators including Nadia Heninger and Emmanuel Thomé.
The papers remain working papers, without conventional peer review. Their significance deserves attention, but the useful story is more specific than AI breaking RSA: researchers used agents to improve a substantial computation and help develop mathematics whose practical consequences still need evaluation.
Three Speedups With Different Evidence
RSA relies on the difficulty of factoring a large integer made by multiplying two primes. Signature attacks can study a different problem: computing new RSA signatures after obtaining signatures on carefully chosen inputs. An advance on that problem need not recover the private key or factor the RSA modulus.
That distinction separates the completed experiment from the second paper’s factoring proposal. The headline numbers also use different baselines.
Reported result
Comparison
Evidence and conditions
About 3.5× less CPU work
391 versus 1,380 CPU-core-years for a known 1024-bit signature-related benchmark
Completed computation; improvement attributed to implementation and execution
About 1,600× improvement
New affine-root algorithm versus the previous method at 1024 bits
Theoretical estimate from an asymptotic cost model, not an end-to-end cryptographic-size run
I’d put the measured 3.5× result first. It has the clearest operational meaning: the researchers report completing an existing benchmark with substantially less CPU work. The larger theoretical figures answer different questions and need different validation.
The Completed Run Did Not Factor an RSA Key
The first paper, Modular Roots from a Restricted Oracle: Faster Affine Roots and a 1024-bit Computation, studies attacks involving temporary access to a signing service, called an oracle.
In this model, an attacker first obtains RSA roots, corresponding to signatures, for chosen inputs. The oracle is then withdrawn. The attacker must compute roots for fresh targets using information collected earlier.
That is a stronger starting position than having only someone’s public key. It can also be much cheaper than factoring the modulus because the attack exploits previously obtained signatures.
According to ByteWoops’ account of the paper, DeepMind’s completed experiment reproduced a previously solved 1024-bit instance from work by Shea, Haller, Suhl, Heninger and Thomé. It used the same algorithm, polynomials and factor-base bounds.
The reported CPU accounting was:
Earlier computation: 1,200 core-years offline, followed by 180 online, totaling 1,380.
New computation: 318 core-years offline, followed by 73 online, totaling 391.
Dividing 1,380 by 391 gives approximately 3.53. Expressed another way, the new run used about 72% less reported CPU work.
A CPU-core-year is an accounting unit: one processor core working for a year. Thousands of cores can accumulate many core-years in a short calendar period. It is neither a dollar price nor a complete measure of a heterogeneous system’s hardware requirements.
The authors attribute this improvement to implementation and execution, not a new algorithm for that completed run. Tao Nhu’s analysis reports that an optimized sieving implementation ran 1.8–4.4× faster than stock CADO-NFS on the same machine.
Keeping the mathematical instance and algorithm fixed makes this comparison useful: the reported gain concerns how efficiently the computation was carried out. It should not be relabeled as an experimental validation of every new algorithm in the paper.
The same reporting puts the estimated cost of factoring that modulus outright at 500,000 to 1,000,000 core-years. That is an estimate for a different task, but it explains why completing the root computation is not equivalent to factoring a general 1024-bit RSA key.
What Signature Padding Changes
Signature padding places data inside a structured block before RSA’s mathematical operation. The paper asks how much protection that structure provides when an attacker can choose part of the input submitted to a signing device.
An unrestricted oracle accepts arbitrary inputs. An affine oracle accepts inputs of the form c + z: a fixed component, c, plus a limited caller-controlled offset, z. This models an interface that wraps caller-supplied data in a prescribed format.
The first paper contains two theoretical advances alongside its completed benchmark.
Caller Control Determines the Relevant Attack Model
The researchers show that an affine oracle with a sufficiently large variable window can simulate an unrestricted oracle using two queries per simulated query. The threshold is roughly a square-root-sized window relative to the modulus, corresponding to control over about half the input bits.
For a 1024-bit block, half the block is 512 bits, or 64 bytes. Tao Nhu’s explanation maps the result to specific signing interfaces:
Raw RSA through CKM_RSA_X_509 corresponds to the unrestricted model.
CKM_RSA_PKCS, with sufficiently long caller-supplied data, can fall into the effectively unrestricted case.
A 32-byte digest, such as a SHA-256 digest, leaves a smaller controlled region and remains in the harder affine case.
Mechanisms that hash messages inside the device are outside these two oracle models.
The half-block description is a useful guide, not a universal rule for every signature standard. ByteWoops notes that the paper’s exact 1024-bit boundary involves measurements alongside its proved range.
The practical lesson is that “the device adds padding” is an incomplete security description. The interface’s permissions matter: what the caller chooses, how much they choose and whether the device hashes the message internally all affect which analysis applies.
The 1,600× Figure Is an Estimate
For the more constrained affine problem, the paper improves the theoretical algorithm using techniques including multistage early-abort smoothness testing and an extended factor base.
Smoothness testing looks for numbers that can be expressed using relatively small prime factors. Early-abort methods try to avoid spending full effort on candidates that look unpromising.
DeepMind translates the improved asymptotic cost into an estimated 1,600× advantage at 1024 bits. Kohli’s announcement explicitly presents this as a theoretical estimate.
Tao Nhu’s breakdown explains that the calculation substitutes 1024-bit parameters into the asymptotic expression while setting its lower-order term to zero. The new affine algorithm was not run end-to-end at cryptographic size; making it practical remains an open problem.
An asymptotic improvement can be scientifically important without predicting a particular machine’s runtime accurately. Implementation overhead, memory requirements and lower-order terms still matter at a fixed key size.
Fan Factories Spread Work Across Many Targets
The second paper, Fan Factories: Multiple Number Fields in Factorization Factories and Batch NFS, is dated November 5, 2026, according to Neural Brew’s account.
It concerns factoring many integers of the same size using the Number Field Sieve, or NFS. The proposed construction shares a large preparatory computation across multiple targets.
The paper reports a precomputation cost roughly comparable to one factorization. After that preparation, its leading-order estimate puts the amortized cost for each additional 1024-bit target at approximately:
One fifty-eighth of standard NFS, or
One thirtieth of the cost of the earlier comparable batch method, associated with Coppersmith’s multiple-number-field approach.
Those figures have different denominators. They are two comparisons of the proposed method, not speedups that can be multiplied together.
The accounting is easier to understand with a simple expression. If shared preparation costs P, each target costs C, and the batch contains k targets, the average cost is:
That equation is an explanation of amortization, not a reproduction of the paper’s full cost model. It shows the essential condition: the up-front work becomes less important per target as the batch grows.
For a small batch, the preparation can dominate. A low marginal cost for another key therefore cannot be read as the cost of attacking one isolated key from scratch.
Lean Checks the Algebra, Not the Runtime
The fan-factories work includes algebraic identities checked in Lean 4, a proof assistant. That gives a machine-checked basis for those identities, a meaningful safeguard when AI systems contribute mathematical constructions.
The speed estimates have a separate status. They rely on standard NFS heuristics and leading-order analysis, and no fan-factory implementation has completed the proposed 1024-bit factorization workload, according to Neural Brew.
My reading is that the evidence has three distinct layers: checked algebra, heuristic complexity analysis and practical implementation. Progress in the first layer strengthens the research, but it does not supply the missing runtime and resource measurements in the third.
What the AI Agents Actually Did
The completed benchmark provides the clearest account of agent-assisted engineering.
The paper describes two cooperating agents, named only Model A and Model B. Tao Nhu’s account describes their division of labor:
Model A supervised: it wrote the design, assigned CPU and memory budgets, established checks, audited results and made go/no-go decisions.
Model B executed: it wrote and tested code, launched and monitored distributed jobs, and repaired failures.
A human researcher directed the task: the human selected the goal and instance and approved irreversible steps.
The workflow included roughly 20 short human messages, mostly approvals, according to the paper accounts. That is evidence of substantial delegated work, but the researcher’s choice of problem, available infrastructure and approval authority remained part of the setup.
ByteWoops reports about 33,500 lines of new code, 336 distributed experiments, and infrastructure reaching approximately 300,000 CPU cores and 16 GPUs. The computation reached a verified root 3.2 days after the first full-scale sieving job.
That clock did not begin at the start of the broader research project. The paper also attributes much of the calendar-time difference from the earlier work to parallelism. A short elapsed time and reduced aggregate CPU work are separate achievements.
The workflow’s checkpoints are particularly instructive. Stages first ran on probes or small canary workloads, and the oracle batch required agreed checks before proceeding. Even then, the agents encountered a 32-bit index overflow that made an initially computed root wrong, according to Tao Nhu.
That failure gives the validation story substance. Code generation and large-scale execution were insufficient on their own; the workflow needed explicit checks capable of detecting an incorrect mathematical output.
For teams designing research agents, I’d pay more attention to that separation of planning, execution and auditing than to the line count. The reported result came from agents operating inside a controlled process with budgets, checkpoints and a final verifiable target.
What Security Teams Can Take From This
DeepMind’s stated boundary remains the most important deployment detail: these findings do not threaten deployed RSA-2048 or larger RSA systems, or modern schemes, through the reported attacks. That is the scope of these results, not a guarantee about every implementation.
For organizations retaining legacy RSA-1024, the work adds evidence in favor of retirement. The signature analysis also supports a more specific review: document which signing mechanisms are exposed, what callers can control and where hashing happens.
The scientific contribution is concrete but unevenly validated. One large computation finished with substantially less reported CPU work. A new affine-root algorithm and a batch-factorization construction offer theoretical improvements, with different remaining implementation questions. Human-guided agents contributed across both mathematics and engineering, while the evidence still depends on the checks appropriate to each task.
Frequently Asked Questions
3 questions
1
Did DeepMind’s AI Break RSA?
No general RSA break was reported. The work concerns legacy 1024-bit parameters, specific signing-oracle models and a theoretical batch-factoring method. DeepMind says RSA-2048 and modern schemes are unaffected by these results.
2
Which Speedup Was Actually Measured?
The completed benchmark used 391 CPU-core-years versus 1,380 reported previously, about 3.5× less CPU work. The 1,600× affine-root improvement and the batch-factorization advantages are theoretical estimates.
3
What Did Lean Verify?
Lean 4 checked algebraic identities in the fan-factories construction. It did not measure an implementation’s speed, validate the complete resource estimate or demonstrate an end-to-end RSA factorization.
