1,600x is arithmetic, not an attack: I checked DeepMind RSA

My calculator says 1,645.7. DeepMind says "about 1,600x." The two numbers agree — and that agreement is the least interesting thing about this story, because the 1,600x was never run. What was actually run is smaller, stranger, and more important: two AI agents reproduced a 1,380-CPU-core-year attack in 391 core-years, debugging it in under four days, on about twenty short messages from a human.

What DeepMind actually announced

On November 6, 2026, Google DeepMind's Pushmeet Kohli posted "Advancing the frontier of cryptanalysis," describing two working papers from a team led by Dj Dvijotham and Abhradeep Thakurta, with cryptographers Nadia Heninger (UC San Diego / Inria) and Emmanuel Thomé (Inria). The target is 1024-bit RSA — a key size NIST stopped accepting for new signatures in 2013. The papers themselves say it in bold: nothing here threatens deployed cryptosystems using 2048-bit and larger RSA. Keep that sentence in mind; every number below lives inside it.

Two columns: measured vs. estimated

The announcement mixes two kinds of numbers, and the papers keep them in separate columns. Here they are, separated:

MEASURED (ran in a sandbox, on a solved benchmark key):
  Original attack, Sep 2026 (Shea/Haller/Suhl/Heninger/Thomé): 1,380 CPU core-years
  Agents' reproduction, same algorithm/polynomials/bounds:        391 CPU core-years
  Ratio: 1380 / 391 = 3.53x less CPU time
  Oracle queries before target selection: ~4.06 billion (original: 2^32 = 4.29B)
  Debugging time: under 4 days, ~20 short messages from a human researcher
  Cost vs. factoring the key outright: < 1/1000

ESTIMATED (theoretical, not run at cryptographic size):
  Signature forgery, 32-byte fingerprint: ~1,600x faster than previous best
  Batch factoring, each extra 1024-bit key: ~30x cheaper than previous batch method
  Fan-factory precomputation: each further key at ~1/58 the cost of plain NFS
  Algebraic identities behind both: machine-checked in Lean 4
  Fan factories built: 0

The measured column is a 3.5x engineering saving on a reproduction. The estimated column is where the 1,600x lives. Both columns are real work; they are not the same kind of claim.

I re-ran the 1,600x with a pocket calculator

The 1,600x comes from the L-notation constants in the affine-roots paper: the old algorithm costs L_N[1/3, 1.8171], the new one L_N[1/3, 1.5803], where L_N[1/3, c] = exp(c · (ln N)^(1/3) · (ln ln N)^(2/3)). For N = 2^1024, that exponent base is 31.275. So the ratio is just exp(31.275 × (1.8171 − 1.5803)):

import math
lnN = 1024 * math.log(2)
f = (lnN ** (1/3)) * (math.log(lnN) ** (2/3))   # 31.275
def L(c): return math.exp(f * c)
print("old/new  :", round(L(1.8171) / L(1.5803), 1))   # 1645.7
print("GNFS/new :", round(L(1.923) / L(1.5803), 1))    # 45158.0
print("NFS/fan  :", round(L(1.923) / L(1.793), 1))     # 58.3
print("MNFS/fan :", round(L(1.902) / L(1.793), 1))     # 30.2
print("1380/391 :", round(1380 / 391, 3))              # 3.529

old/new  : 1645.7
GNFS/new : 45158.0
NFS/fan  : 58.3
MNFS/fan : 30.2
1380/391 : 3.529

1645.7 against a claimed ~1,600; 58.3 against ~1/58; 30.2 against ~30x. The arithmetic behind all three headline multipliers reproduces from the papers' own constants, using the standard GNFS constant 1.923 and the standard multiple-NFS constant 1.902. That is a genuine check — it means the big numbers are not typos or marketing rounding. But it is also all it is: L-notation is asymptotic. It says what the cost would be at the limit, with the constants doing the talking and the implementation doing none of it. The 1,600x algorithm was not run at 1024 bits. The fan factory was not built at all — the paper's own analysis notes the shared table would be enormous, roughly 275 pairs at leading order for 1024-bit targets, and the batch variant without that stored precomputation has a much smaller gain.

The part nobody headlined

The most consequential sentence in this story is not DeepMind's. It is from the September paper the agents reproduced — Shea, Haller, Suhl, Heninger and Thomé, "Forging 1024-bit RSA signatures in nearly SNFS time," IACR ePrint 2026/2131, September 20, 2026. I fetched it and checked the claims against the text:

ePrint 2026/2131 — verified from the paper itself:
  Title: "Forging 1024-bit RSA signatures in nearly SNFS time"
  Cost of the original attack: 1,380 CPU core-years over 5 months, 2^32 oracle queries
  Conclusion: RSA's concrete security is "15 to 30 bits lower than
              factoring-based estimates" for keys from 1024 to 4096 bits
              "in this attack model" — i.e., with a signing oracle.
  Sharpest line: "Even 4096-bit RSA does not appear to meet a 128-bit
              security level in this attack model."

Read that again: the September paper already concluded that 4096-bit RSA falls short of 128-bit security once the attacker gets a signing oracle — a hardware security module, a signing API, anything that signs attacker-influenced data and returns the signature. DeepMind's agents then made the forgery cheaper (3.5x measured, 1,600x projected) and the batch case cheaper (30x projected). The agents did not discover that the oracle model is dangerous. The humans did, in September. The agents made an existing warning louder, faster, and cheaper to act on.

That reframes the "weeks, not decades" line, too. What took weeks was the agents' run through a problem cryptographers had already framed, with the polynomials and bounds handed to them from the September paper. The human contribution is visible in the paper trail: Heninger and Thomé co-authored both the September attack and the November follow-ups. "Two agents, ~20 messages, under four days" is a real measurement of implementation speed. It is not a measurement of autonomous discovery.

What actually changed

Three things, in order of how much I trust them:

1. The measured 3.5x is real and it is the story. Reproducing a 1,380-core-year computation in 391 core-years, in under four days of debugging, means the iteration loop on cryptanalysis just got dramatically shorter. The next attack idea gets tested in weeks instead of years — and the testing is what produces the next theoretical jump.
2. The 1,600x and 30x are sound arithmetic on unbuilt machines. My re-derivation matches DeepMind's constants to within rounding. But asymptotic estimates have a history of shrinking on contact with implementation — the fan factory's own paper says as much about its stored table — so treat them as directions, not arrival times.
3. The oracle model is the actual vulnerability, and it predates the agents. Padding was supposed to stop forgery; the papers show that once an attacker controls about half the signed block, padding buys almost nothing, and a 32-byte digest is a genuinely hard case that just got 1,600x cheaper on paper. If your threat model includes a signing oracle — an HSM, a cloud signing API, a blind-signature flow — the September paper's "15 to 30 bits lower" is the number to carry, not the 1,600x.

RSA-2048 is untouched by these specific results, and nobody involved claims otherwise. What moved is the speed at which the safety margins get re-measured — and the uncomfortable fact that the margins were already thinner than the textbooks said, before any agent got involved.

Sources: Pushmeet Kohli, "Advancing the frontier of cryptanalysis," Google DeepMind, Nov 6, 2026; "Modular Roots from a Restricted Oracle: Faster Affine Roots and a 1024-bit Computation" and "Fan Factories: Multiple Number Fields in Factorization Factories and Batch NFS," Google DeepMind working papers, Nov 5–6, 2026; Shea, Haller, Suhl, Heninger, Thomé, "Forging 1024-bit RSA signatures in nearly SNFS time," IACR ePrint 2026/2131, Sep 20, 2026 (fetched and checked Nov 8, 2026). All L-notation ratios and the 1380/391 division are my own computations from the papers' published constants; the 1,600x and 30x figures are DeepMind's theoretical estimates, not measured results, and the papers are working papers, not yet peer-reviewed.