Three numbers, three kinds of evidence

The coverage of this announcement mostly runs on one number, 1,600x. The papers contain three numbers, and they are not the same kind of claim.

The 3.5x is measured. DeepMind's agents re-ran the exact computation Shea, Haller, Suhl, Heninger and Thomé published earlier this year, with the same algorithm, the same polynomials and the same bounds, and the first root took 391 core-years against their 1,380.

The 391-core-year figure measures the reported CPU work for the completed computation. It excludes GPU work and preliminary probes and rehearsals. It is therefore the appropriate comparison for the paper's stated CPU benchmark, not a complete accounting of every computing resource used in the research. Counting the excluded work, the paper's own adjusted comparison is about 3.3x.

The paper is blunt about what the saving is: implementation and execution, not a better algorithm. The optimized siever runs 1.8 to 4.4 times faster than the standard CADO-NFS siever on the same machine and finds the same relations.

The 1,600x is not measured. It is DeepMind's announcement-level estimate for the harder signature-oracle case, where an attacker controls only a short input such as a 32-byte digest. The working paper lowers the asymptotic cost exponent from 1.8171 to 1.5803, but does not report a 1,600x experimental result. The improved algorithm has not been run at any cryptographic key size. Its projected cost depends on standard number field sieve heuristics. Treat 1,600x as DeepMind's theoretical estimate, not a demonstrated reduction in running time.

The approximately 30x batch-factoring improvement is a leading-order estimate, not a measured running-time reduction. The method first requires precomputation costing approximately one conventional factoring run. With lower-order terms set to zero, the paper estimates that each additional 1024-bit integer would cost about 1/58 of a conventional GNFS run, roughly 30 times less than the previous batch method at a comparable precomputation budget. The authors explicitly warn that these estimates do not predict actual running times. Without precomputation, the improvement is at most 0.018 in the asymptotic exponent.

What the agents actually did

The part of this story most likely to matter in five years is not RSA. It is the division of labor in Section 6 of the signature paper.

Two agents ran the computation. A supervisor model wrote the design, set the resource budget for every stage, fixed the checks each stage had to pass, and audited the executor's results. An executor model wrote the code, launched and monitored 336 distributed experiments, and diagnosed the failures, including a 32-bit index overflow that made the first computed root wrong and descent nodes that appeared only at full scale. A rehearsal at 498 bits had passed cleanly and exposed none of it. The human researcher chose the problem and the instance, approved the steps that could not be repeated, and sent about twenty short messages, most of them approvals. The paper's sentence is worth taking at face value: the researcher wrote no code, launched no job and diagnosed no fault.

Two cautions belong next to that. The agents completed the broader reported workflow in 3 days and 22 hours, while the paper separately reports approximately 3.2 days for the full-scale computation. Neither duration should be read as a direct measure of agent speed. The comparison with approximately five months for the earlier team mainly reflects parallelism: the new run used up to about 300,000 CPU cores. And the agents were re-running a computation whose algorithm, parameters and public code already existed. Designing, optimizing and debugging a known pipeline at scale is a large amount of real research engineering. It is a different claim from originating the method, and the paper does not make that claim.

The assumption underneath, and the one practical instruction

Both results sit on a strong access assumption. The signature model gives the attacker a signing interface that answers billions of chosen inputs before the target exists. That models a real class of device, a hardware signer that applies a fixed format to caller data, which is why the format threshold matters. Under the paper's oracle model, when the caller controls more than roughly half the signed block, the PKCS#1 v1.5 formatting adds no asymptotic difficulty beyond the corresponding unrestricted modular-root problem. But signers that hash inside the device are outside the model, and no deployed product is shown to satisfy the model's conditions. This is a measurement of how much freedom a standard's format leaves, not a demonstration against a named system.

The practical instruction is therefore narrow and was already overdue. Systems still generating signatures with 1024-bit RSA already warrant migration under longstanding cryptographic guidance. These papers add reasons to examine legacy signing interfaces, especially those that expose caller-controlled data to a signing operation. They do not establish a working attack against every 1024-bit RSA deployment. For everyone on 2048-bit keys or better, this announcement changes nothing about today's risk. What this case demonstrates is that AI agents can automate substantial implementation, experiment management and debugging work in a known cryptanalytic pipeline. Whether that translates into faster discovery of new attacks remains an open question. DeepMind has published the working papers so the field can check whether the measurements, rather than the announcement, survive contact with other cryptographers.

Sources

  1. [1] Google DeepMind, "Modular Roots from a Restricted Oracle: Faster Affine Roots and a 1024-bit Computation", working paper, read in full this run (official PDF): threshold result for formats above half a block and the 64-byte digest case at 1024 bits; affine cost exponent 1.8171 to 1.5803; the 391 vs 1,380 core-year reproduction and its implementation-not-algorithm caveat; the Section 6 agent setup (supervisor/executor, about 20 human messages, 33,500 lines, 336 experiments, up to 300,000 cores, 3 days 22 hours); the Section 7 scope limits (hash-inside signers outside the models, 2048-bit estimates asymptotic, affine algorithm not run at cryptographic size)Read source
  2. [2] Google DeepMind, "Fan Factories: Multiple Number Fields in Factorization Factories and Batch NFS", working paper dated 5 November 2026, read in full this run (official PDF): per-integer exponent 1.7929 against 1.9019 with a one-factorization precomputation; the leading-order 1/58 and roughly 30x figures with the paper's own warning that they do not predict running times; batch-mode gain of at most 0.018; Lean 4 machine-checked identities; two-agent proof harnessRead source
  3. [3] Pushmeet Kohli (Google DeepMind), "Advancing the frontier of cryptanalysis", X article, 6 November 2026, as reported consistently by multiple secondary accounts this run: the announcement framing of the two results and the roughly 1,600x summary of the affine improvement
  4. [4] Shea, Haller, Suhl, Heninger and Thomé, "Forging 1024-bit RSA signatures in nearly SNFS time", Cryptology ePrint Archive 2026/2131: the original 1024-bit computation (about 1,200 core-years offline and 180 online) that the DeepMind agents reproduced, as cited inside the DeepMind paper