DeepMind AI Agents and 1024-Bit RSA: What Was Tested

Google DeepMind said on November 6 that AI agents, guided by human researchers, found two ways to attack 1024-bit RSA keys more cheaply. Pushmeet Kohli, DeepMind’s head of science, announced it in an essay on X and put two working papers online. Headlines picked up the big multipliers: “1,600x faster”, “30x cheaper”.

I read both papers’ abstracts. The multipliers are in there, but so is a plainer fact: the single thing the agents actually ran was the least dramatic result.

The number that was measured: 391

A team including Nadia Heninger and Emmanuel Thomé published a hand-built forgery attack on 1024-bit RSA signatures earlier. DeepMind’s first paper says its agents reproduced that computation “with the same algorithm, polynomials and bounds”, and the first root took 391 CPU core-years, 3.5 times less than the original. Two cooperating agents designed, ran and debugged it in under four days, according to the paper. A core-year is one processor core working for a year, so this was a big cluster job, not a laptop trick.

The original study took about 1,380 core-years, per the secondary coverage I read, which squares with the 3.5x claim (1,380 divided by 391 is 3.53). Same method, better engineering. That’s a real result, and it’s a fair thing to credit to the agents. It is not a new attack.

The numbers that weren’t

Everything bigger is on paper. Here’s how the announcement’s figures line up with what each paper says about itself.

Claim	What backs it	Run at full size?
Reproduced forgery used 3.5x less CPU time	391 vs about 1,380 core-years	Yes
New forgery algorithm about 1,600x better for a 32-byte digest	Kohli’s “theoretical estimates”	No
Each extra key in a batch costs about 30x less	Leading-order math, o(1) terms set to zero	No
Padding stops helping once the caller controls about half the block	Proof in paper 1	Argued, not run on padded keys

The 30x comes from the second paper, which says a shared precomputation worth one factorization would let each further 1024-bit key be factored at about 1/58 of the normal cost. It states the result “at leading order”, with the correction terms ignored, and holds “under the standard heuristics” of number field sieve analysis. The authors say the algebra is machine-checked in Lean 4. A proof that the algebra is right is not a factoring run.

Both are working papers. Neither is peer reviewed, and I haven’t seen anyone outside DeepMind report repeating them.

What the padding finding says

RSA signing devices don’t sign your raw data. They wrap it in fixed filler first, a format called PKCS#1 v1.5, so a 1024-bit key signs a 128-byte block. The first paper asks how much that filler protects when an attacker can send the device chosen data and collect signatures. Its answer: once the caller supplies more than half the block, or a 64-byte digest at 1024 bits, the filler makes the problem no harder than the unpadded one. A 32-byte digest, the SHA-256 size, still leaves a harder problem, and that’s where the 1,600x estimate lives.

Per WebProNews, the setting is a hardware security module that signs data an attacker supplies.

Who needs to care

Not most people. DeepMind says so itself, in a box at the top of each paper: the results “don’t threaten deployed cryptosystems today that are based on 2048-bit and larger RSA.” NIST’s guidance, which the secondary coverage cites, doesn’t allow keys under 2048 bits for new signatures and keeps 1024-bit only for checking old ones.

My read: the people who should pay attention are the ones with old gear: firmware signing keys nobody rotated, embedded devices, legacy signing hardware. If that’s you, the message is the same as it was a year ago, only louder. Move off 1024.

My read

I don’t think the cryptography is the story. The part I keep thinking about is the speed claim in the abstract: “under four days” for a computation that took human experts far longer, done by two agents checking each other. Whether the algorithms are as good as claimed will take outside cryptographers months to settle. Whether agents can now do this kind of grunt work well is already answered by the 391.

My other reaction is plain annoyance at the packaging. A 1,600x headline for an unrun estimate, next to a 3.5x that actually ran, invites readers to swap the two. The papers themselves state their limits clearly.

For comparison, we covered Claude finding VM-escape flaws in Xen, where the bugs were real and patchable. Here the thing to watch is the follow-up: a peer reviewed version, or an independent group running the batch method on actual 1024-bit numbers.

Sources

Note on sources: the papers and Kohli’s post are DeepMind’s own, so every figure here is DeepMind’s claim. The 1,380 core-year figure for the original study, the peer-review status and the NIST key-size rule come from secondary coverage (Interesting Engineering, WebProNews and others) and I did not check them against the original study or NIST’s documents. I could not load Kohli’s full essay, only the papers’ abstracts and the coverage of it.