Google DeepMind says AI agents cut a 1024-bit RSA forgery to 391 core-years; the factoring claim is theory

391 core-years, and a factor of 3.5 that the paper says is about code

Add the two stage totals in Table 2 of the DeepMind affine roots paper and the first 1024-bit root cost 391 CPU core-years: 318 offline plus 73 online. The earlier computation it re-ran reported 1,380, which is 1,200 plus 180. Dividing gives 3.53 (derived), which the paper rounds to 3.5, and the paper's own verdict on that factor is that it is "one of implementation and execution, not of algorithms". Google DeepMind's two papers were reported by SecurityWeek at 08:35 UTC on 9 November 2026 (the article's own timestamp); the fan factories paper is dated 5 November 2026 on its first page, and the affine roots paper prints no date on the pages read. This briefing was written from both papers, read in full at 10:55 UTC on Monday 9 November 2026.

That figure does not establish a break. No key was factored: the paper says its results "do not recover the key". The oracle that answered 4,055,916,065 signing queries was, in the paper's words, "a separate program, the only one with access to the factorization of N", and the modulus came from the earlier academic study. Neither paper reports a real device forged, a deployed key attacked or a vendor product exposed. Both carry the same warning, here from the fan paper: "Our results do not threaten deployed cryptosystems today that are based on 2048-bit and larger RSA."

The second headline, factoring each further 1024-bit key at about 1/58 of the cost of the number field sieve and 30 times less than its multiple-field variant, is a different kind of claim. It is a leading-order estimate with the o(1) terms set to zero, under standard heuristics, and the fan paper says plainly that "no fan factory has been implemented". Both are Working Papers by Google DeepMind with named co-authors from UC San Diego and Inria; the first page of each says so, and nothing in either says it has been peer reviewed. Google sells AI and cloud services, and both papers present AI-assisted research as their main significance; that is the publisher's interest, stated once.

Two papers, three results, one warning

The first paper studies computing e-th roots modulo a fixed composite N, which is the RSA problem, when an oracle can be asked for roots during an offline phase and is then withdrawn. It has three results. A format result: a fixed signing format stops mattering once the caller chooses about half of the block. An algorithm result: a lower cost for the harder case where the caller chooses less. And one complete computation at 1024 bits, which is the 391 core-year figure.

The second paper is about factoring many integers of the same size. It gives each integer its own family, or fan, of number fields, all fed by one shared precomputation. It reports a closed form for the cost per integer at every precomputation budget and, at 1024 bits, the estimate of 1/58 of a factorization per further key. It is a theory paper: the abstract says the results hold "under the standard heuristics of NFS analyses".

The AI claim is the authors' own. In the affine paper, "two cooperating AI agents" designed, ran and debugged the computation, named only as Model A, a supervisor, and Model B, an executor. In the fan paper, "a two-agent AI harness" had one model generate the proofs and a second verify them. Neither paper names the models, their versions or their vendor, and neither says how much of the mathematics the agents found compared with what the human authors already knew.

Zoom

The attack model in plain words, and where padding stops mattering

In the paper's model, signing a block means taking its e-th root modulo N, which only the holder of the factorization can compute directly. The model asks what an attacker can do with temporary access to a signing device. In an offline phase the attacker chooses inputs and the device returns their roots. The device is then withdrawn. In an online phase the attacker must produce the root of a random target without it. The queries are chosen before the targets are known, which the paper calls non-adaptive.

Two oracles have been studied. An unrestricted oracle accepts any residue. An affine oracle accepts only a fixed part c plus a small caller-chosen part z, which the paper says models "signing interfaces that apply a fixed format to the caller's data". The paper's first result is that for the PKCS#1 v1.5 format used by the PKCS#11 mechanism CKM_RSA_PKCS, a caller who chooses more than about half the block gets a problem "no harder than the unrestricted oracle case", at two queries for each one the unrestricted algorithm would make. At 1024 bits that means 65 of the 128 bytes, and the mechanism allows up to 117.

Zoom

Zoom

The paper then lists three limits on practical reach under the heading Scope. First, the largest size at which the unrestricted algorithm has been run is 1024 bits, which the paper calls "a size no longer approved for generating signatures", and at 2048 bits every cost estimate is asymptotic. Second, the model requires "direct calls to the signing interface with inputs of the caller's choice, rather than calls through an application that hashes the message before signing". Third, "the number of calls is large": about 4 billion, all made before the target is known. For a device on CKM_RSA_PKCS with long data, the paper says the query count is doubled, which is about 8.1 billion (derived).

The papers publish no throughput for any real device. As arithmetic only: each 1,000 queries per second a device sustains turns 4,055,916,065 queries into about 47 days (derived) of continuous access. The rate is a unit chosen by this site, not a measured or published figure, and the papers do not say how an attacker would get such access.

What was actually run for 391 core-years

The computation is the algorithm of an earlier study from UC San Diego and Inria (the paper cites it as ePrint 2026/2131, which is also where the 1,380 figure comes from), re-implemented in C++ on top of the CADO-NFS number field sieve code, with the same modulus, polynomials and factor-base bounds. The target was derived after the oracle was withdrawn from a public seed string, and the root was checked against it. Table 2 of the paper is the ledger.

What the 391 leaves out. The linear algebra ran on GPUs, about 330 GPU-hours reserved and about 100 busy, and is not counted. Charging it at the earlier 17 core-years gives a factor of 3.4, and adding 7.5 core-years of probes and rehearsals gives 3.3, both from the paper. Polynomial selection was reused from the earlier study. The comparison is against costs "obtained on their hardware", so it is not a same-machine test.

Where the saving came from. The paper says the same algorithm ran on the same polynomials, so the factor measures implementation. Sieving accounts for 90% of the saving, 80% from the second tier alone. On one machine, the optimised siever found the same relations as the upstream one and was 1.8 to 4.4 times faster. The paper calls it "a faster AI-optimized version of the CADO-NFS lattice siever". How much of that speed-up the agents produced, compared with what a human engineer could have done, is not stated.

Calendar time. The paper gives 3.2 days from the first full-scale sieving job to the verified root, against about five months for the earlier study, and says the difference "reflects mainly parallelism". The run averaged about 45,000 cores, with peaks of about 300,000 CPU cores and 16 GPUs. A check this site made: 3.4 million core-hours over 3.2 days is about 44,000 cores on average (derived), which agrees. The abstract's "under four days" runs on a different clock: 3 days 22 hours, 94 hours (derived), from the start of the design to the verified root. The oracle batch itself took 20 minutes.

The agents' log is the most useful part for defenders who run AI on long jobs. A 32-bit index overflow made the first computed root wrong, and the check that the root raised to the power e matches the target is what caught it. Table 4 of the paper lists four problems that appeared only at 1024 bits, none of which needed the oracle batch to be repeated. The paper also describes a gated workflow, with checks fixed in advance before each stage spent compute, and a rehearsal at 498 bits before the real target was drawn.

The factoring claim: theory, at leading order, with the o(1) set to zero

The fan paper's exponents are a statement about how cost grows, written LN[1/3, c]. The number field sieve has c of about 1.923, Coppersmith's multiple number field sieve (MNFS) about 1.9019, and with a precomputation costing about one factorization the fan factory reaches 1.7929. The paper stresses that the hidden o(1) factors are not determined: setting them to zero gives estimates that "indicate the size of an improvement but do not predict running times".

Read the 2048-bit row as the paper does. The precomputation is a full factorization of that size, about 2^116.9 operations at leading order, and each further key is still about 1/240 of that: about 2^109 (derived). The paper's Scope paragraph makes the same point, and the authors state that the results do not change the security of RSA moduli of 2048 bits or more. At 1024 bits the gain over MNFS is the 30 in the abstract; against the plain number field sieve it is the 1/58.

So the 30 times is a per-key figure for keys after the first, which only a large batch approaches. SecurityWeek wrote "on average"; the paper's own arithmetic gives 19 times at 100 keys and 28.5 times at 1,000 (both derived). The paper also bounds where the fan helps: only for a precomputation budget of between about half a GNFS run and about 2.3 GNFS runs at 1024 bits. With an unlimited budget Coppersmith's older factory is optimal, at about 14 GNFS runs of precomputation and 1/7300 of a run per integer, and for a single integer nothing changes.

Memory is a second obstacle, and the secondary does not mention it. At a budget of one GNFS run the stored table holds about 2^75 pairs at 1024 bits at leading order (the paper prints the exponent as a superscript; 75 is also what this site derives from the paper's L[1.6603] and its 31.27 conversion factor). Batch mode stores no table, but its cost in the area-time model in which storage is expensive is listed as open.

What "machine-checked" covers. The paper says the algebraic identities and exact feasibility witnesses at four budgets are checked in Lean 4, and that the calculus arguments are "proved in the text and were checked numerically". The Lean source is in a full version that was not among the saved sources. The heuristics H1 to H3 are the standard unproven ones of number field sieve analysis, and the paper says no assumption specific to fans is needed. A proof assistant does not check a heuristic.

Labels doing the work of a control

"Padded" is not a control against a caller who chooses the block. The format adds fixed bytes. The first paper's point is that once the caller supplies about half the block the fixed part adds no cost, "a property of the format itself", so it "holds for every correct implementation of it".

"The key never leaves the device" is not the same as "the signing interface is safe to expose". The earlier UC San Diego and Inria abstract describes carrying out its attack "using a hardware security module (HSM) as the signing oracle" and impersonating the HSM "without exfiltrating the key". That is the earlier team's claim, from the abstract page only. The device was not named there, and DeepMind's own run used a software oracle.

"Hashed inside" means outside this model, not outside all models. The paper's wording is that such mechanisms are "outside both oracle models". It is a statement about two named models, not a clearance.

"AI found it" is not a measure of the result. The 3.5 times is measured and mostly code; the 30 times is a leading-order estimate; the exponents either hold under the stated heuristics or they do not. The AI label tells a reader how the authors say the work was done, not how much to trust it.

What the papers state, and what they do not

DeepMind's own announcement was not found. The executive's quotes in SecurityWeek link to a post on X, which this site does not read, and a search of the deepmind.google sitemap (latest change dated 6 November 2026), of its blog index and of the blog.google sitemap found no post on these papers. The quotes SecurityWeek attributes to a Google DeepMind executive are therefore SecurityWeek's only, and nothing here rests on them.

Where the sources differ

Who still has 1024-bit RSA, and what the standard says

Neither paper, nor the NIST document read for this briefing, gives a count of 1024-bit keys in use, and this site gives none. What the sources do say: the affine paper calls 1024 bits "a size no longer approved for generating signatures" and cites NIST SP 800-131A Rev. 2. That document, published March 2019 on its cover, lists RSA signature generation with a modulus length below 2048 as Disallowed and 2048 or more as Acceptable, and lists RSA with a modulus of 1024 to under 2048 bits as Legacy use for signature verification only.

As read on NIST's page, a planning note dated 21 October 2024 says an initial public draft of Revision 3 was open for comment until 4 December 2024. That draft was not read, and whether Revision 3 has been finalised, or changed this table, was not checked. Which devices still hold such keys is not stated in any source read here.

What to do, in order

Technical details

Do the papers publish a usable attack tool? As read, no. They give the algorithm in outline, the exponents, one measured computation and a table of costs. Both defer the full algorithm, the proofs, the parameters and the Lean source to a "full version" that was not among the sources, and neither links code. Everything below is printed text copied from the saved papers, so it helps a defender read the claims and does not help anyone forge a signature. Each block says what it is and where it came from.

The abstract's exponents for the affine problem. LN[1/3, x] is the standard notation for running time growth, and a lower x is cheaper. A defender uses it to see that the claim is about how cost scales, with a larger offline phase buying a lower online cost.

For the affine problem, we lower the cost of computing one root, offline phase included, from
      LN [1/3, 1.8171] to LN [1/3, 1.5803]; with a larger offline phase, of cost LN [1/3, 1.6373] and still
      far below factoring, the online cost per root approaches LN [1/3, 1.3867].

The two oracle definitions as printed. The affine oracle accepts only a fixed value c plus a small caller-chosen z, which is what a signing interface with a fixed format does. This is the property to look for in a device you run.

• an unrestricted oracle, which accepts every residue; and
    • an affine oracle, which, for a fixed residue c and a bound Z, accepts only the residues c + z
      with z ∈ Z and |z| ≤ Z.

Table 1 of the paper, the exponents of each algorithm as printed. Offline and Online are costs, Queries is how many signing requests are needed. Note the last row, where the offline exponent rises to 1.6373 and the online one falls to 1.3867, both still below the cost of factoring in the paper's notation.

Oracle         Algorithm              Queries    Offline    Online   Amortized, M = L[µ]
unrestricted   [JNT07]                 0.7631     1.5263    1.5263    1.5263 for all µ ≥ 0
affine         [JNT07, Section 4.3]   ≤ 1.8171   ≤ 1.8171   1.8171          1.8171
affine         Theorem 3.1(a)          0.9602     1.5803    1.5803      1.5803 at µ = 0
affine         Theorem 3.1(b)          0.9871     1.5930    1.5263   1.5263 at µ = 0.0667
affine         Thm. 3.1(b), s → ∞      1.0704     1.6373    1.3867   1.3867 at µ = 0.2506

The paper's main theorem, as printed. H1 to H5 are the heuristics it assumes.

(a) One target: with three early-abort stages, L[0.9602] queries, offline time L[1.5803] and online
     time L[1.5803].
 (b) Many targets: with four early-abort stages, L[0.9871] queries and offline time L[1.5930], online
     time L[cSNFS ] = L[1.5263] per root; and with L[1.0704] queries and offline time L[1.6373],
     online time per root arbitrarily close to L[(8/3)1/3 ] = L[1.3867] as the number of stages grows.

No choice of the parameters of the method gives offline time below L[cSNFS ].

The PKCS#11 mechanism names the paper classifies, as printed in its Figure 5 (the text extraction prints spaces where the standard uses underscores). A defender maps these onto the mechanisms a device exposes.

CKM_RSA_X_509
CKM_RSA_PKCS
CKM_SHA256_RSA_PKCS

The paper's own Scope paragraph, which sets the limits on practical reach.

Scope. These statements are about the cost of computing roots after temporary access to the
map; they do not recover the key. Three conditions limit

The fan paper's abstract, from the sentence that states the new cost, with its leading-order claim and its scope statement.

We give every integer its own family, or fan, of number fields, all fed by the shared rational
      side, and determine in closed form the smallest cost per integer for every precomputation budget.
      With a budget of one factorization, each further integer costs LN [1/3, 1.793]. More generally, for
      every budget exponent strictly between 1.902 and (2401/324)1/3 ≈ 1.950 the fan improves on all
      previous methods, and above it one field per integer is optimal. For batches of integers factored
      together without precomputation, the exponent per integer improves by at most 0.018. At
      leading order, that is, with the o(1) terms set to zero, a precomputation of one factorization lets
      each further 1024-bit integer be factored at about 1/58 of the cost of factoring it with the NFS,
      30 times less than with MNFS. The results hold under the standard heuristics of NFS analyses,
      and the algebraic identities and exact feasibility witnesses behind them are machine-checked in
      Lean 4.

The heuristics the fan paper's running times assume, as printed. They are the unproven standard assumptions of number field sieve analysis.

(H1) Smoothness. For coprime pairs in the sieve region, the norms F0 (a, b) and F (j) (a, b) are
      smooth with the probabilities (1) that random integers of the sizes in Lemma 2.2(iv) would
      have, and these events are independent across the rational side and the fields of the fan.


                                                      7

(H2) Computational model. Time is measured in the unit-cost RAM model. Sieving a region of
     L[2α] points with a factor base of L[β] ≤ L[2α] primes costs L[2α]. Block Wiedemann [9]
     finds a dependency in a D × D matrix over F2 with L[o(1)] non-zero entries per row in time
     D2 L[o(1)] and memory D L[o(1)].
(H3) Square roots. The fan polynomials are irreducible; a product of elements a − bθj whose
     exponent vector vanishes modulo 2 on the ideal and character columns of field j is a square
     in Q(θj ); and each dependency yields a non-trivial factor of N with probability at least 1/2,
     independently across dependencies.

The question the papers leave open

The papers are careful: the claim is about cost, the proofs are deferred, the factoring result has not been built, and 2048 bits is outside it. What they cannot say is who in your estate could ask an old signing key for four billion answers before anyone looked. If the oldest 1024-bit key you own accepts data of the caller's choosing, who is allowed to call it, and what would notice the four billionth request?

Key facts