DeepMind’s RSA-1024 Results Don’t Mean Today’s Keys Were Cracked

Two Google DeepMind working papers have renewed attention on old 1024-bit RSA. One reports a faster reproduction of a computation against a legacy signature setup; the other develops a theoretical way to lower the cost of factoring batches of similarly sized numbers. Neither paper says that 2048-bit RSA keys in deployed systems were broken. The useful response is careful inventory, not panic.

Two papers, two kinds of evidence

The first paper studies RSA root extraction when an attacker has temporary access to a signing or decryption oracle, then loses access and must compute roots offline. Its authors analyze how the fixed message format used by PKCS#1 v1.5 affects the problem. Under the paper’s conditions, a long enough variable portion can make the formatted interface no harder than an unrestricted oracle; a shorter 32-byte digest at 1024 bits remains a harder affine case with a theoretical improvement in asymptotic cost. Those are formal attack models, not claims that arbitrary internet services expose the needed oracle. ^[1]

The paper also reports a concrete computation: the first root for a previously studied 1024-bit instance took 391 CPU core-years, compared with 1,380 core-years reported by the earlier team for the same algorithm, polynomials, and bounds. That is a roughly 3.5-fold reduction in CPU time from implementation and execution improvements, not a new factoring algorithm that suddenly makes modern RSA keys solvable. The authors say two AI agents designed, ran, and debugged the computation in under four days, using a large distributed run; calendar time and total compute are different measures. ^{[1] [3]}

The second paper proposes “fan factories,” a number-field-sieve strategy that shares some precomputation when factoring many integers of the same size. It improves the theoretical exponent for certain batch settings. Its headline comparisons are leading-order estimates based on heuristic assumptions. The authors explicitly say the method has not been implemented and do not claim it beats a well-tuned practical number-field sieve at any particular size. They also state that the result does not threaten deployed systems based on RSA keys of 2048 bits or larger. ^[2]

Why “RSA was cracked” is the wrong summary

RSA is a family of operations and encodings, not one single button. Factoring a public modulus, forging a signature with access to a constrained oracle, and verifying an old signature are different tasks with different conditions. The papers distinguish these problems; headlines that compress them into “AI broke RSA” erase the conditions that tell a security team whether its own system is affected.

The 391 CPU core-year figure is also easy to misread. It is CPU work accumulated across a distributed computation, not 391 years of elapsed time and not a general-purpose method for recovering any RSA private key. The comparison is a reproduction of a prior result on the same 1024-bit instance. The more ambitious batch-factoring improvement remains theoretical and unimplemented. Keeping measured work separate from asymptotic estimates is essential to understanding the result. ^{[1] [2] [3]}

What a security team should do

NIST’s current Digital Signature Standard specifies RSA modulus sizes of at least 2048 bits for signature generation. Its transition guidance treats weaker sizes as legacy use for processing existing signatures rather than applying new cryptographic protection. That guidance predates these papers; the research is not the reason 1024-bit keys should already be absent from new signing systems. ^{[4] [5]}

If a team still depends on legacy RSA, inventory the key length, protocol, padding mode, signing interface, and any service that can be queried with chosen inputs. Pay particular attention to old hardware modules, timestamping or code-signing services, and internal APIs that may provide oracle-like behavior. Use standards and vendor guidance to plan supported migrations; do not infer exposure from a headline alone. For a broader migration perspective, see our guide to the post-quantum security transition and key-management planning.

The lasting signal is about research velocity. In one paper, AI agents helped execute and debug a difficult computation; in the other, a separate agent workflow contributed to a new theoretical batch method with machine-checked algebraic claims. The papers still distinguish what was run from what was proved under a model. Security teams should keep doing the same: identify the exact construction, access conditions, and key sizes before deciding what the result means for their systems.