Google DeepMind’s November 6, 2026, announcement described two distinct RSA-1024 results: a completed computation of an RSA root under an unrestricted chosen-input oracle model, and a separate theoretical analysis of factoring batches of same-size integers. Neither paper reports factoring a single modulus or extracting its private key. The papers say their findings do not threaten RSA moduli of 2,048 bits or larger.
The key distinction is between one completed computation under a specific oracle model and separate factoring estimates that remain theoretical.
What the RSA-1024 computation involved
The completed computation calculated an RSA root for a 1,024-bit modulus using an unrestricted oracle: a direct signing or decryption operation that accepts inputs chosen by the caller. Google DeepMind reports that the agents made 4,055,916,065 oracle queries before the target was selected; there were no oracle queries during the online root computation. The work did not factor the modulus or extract the key, and the paper says signers that hash inside the device fall outside the oracle models it studied. (Google DeepMind’s computation paper)
That model matters when interpreting the result: it describes a computation requiring direct access to a raw signing or decryption oracle, not a demonstrated exploit against ordinary production signing interfaces.
What the 3.5-fold CPU comparison means
For the first root on the same 1,024-bit instance, Google DeepMind reports 391 CPU core-years, compared with 1,380 CPU core-years in the earlier computation. The papers use the same algorithm, polynomials, and factor-base bounds for this comparison. DeepMind attributes the 3.5-fold difference to implementation and execution efficiency, not to a new attack algorithm; its CPU total excludes GPU work. (Google DeepMind’s paper; the earlier IACR preprint)
A separate short-window method addresses a more restricted affine signing interface. DeepMind gives heuristic asymptotic cost exponents of 1.5803 for its method and 1.8171 for the earlier method, but says the short-window approach was not run at cryptographic size. Those estimates are not measured attack times, and they do not turn the completed unrestricted-oracle computation into a test of a 32-byte-digest production interface. (Google DeepMind’s paper)
What the batch-factoring estimates describe
The separate “fan factory” analysis considers factoring many integers of the same size while sharing preliminary work. For 1,024-bit targets, Google DeepMind estimates that after precomputation equivalent to one general number field sieve (GNFS) run, each additional target would cost about 1/58.5 of a GNFS run at leading order. The paper estimates that per-target cost at about 30.2 times less than with the multiple number field sieve (MNFS), and that total cost becomes lower than MNFS from batches of three targets when precomputation is counted. (Google DeepMind’s fan-factory paper)
These are heuristic estimates, not measured running times: the paper reports no implementation, and the proposed advantage applies to batches rather than reducing the cost of factoring one integer.
How the agents and researcher divided the work
Google DeepMind’s paper describes a supervisor agent that managed the design, budgets, checks, and stage decisions, and an executor agent that wrote and tested code, ran jobs, and diagnosed failures. A human researcher chose the task and approved key gates, including steps involving the oracle and target selection. The paper says the researcher wrote no code, launched no jobs, and diagnosed no faults; it reports about 20 human messages and 336 distributed experiments. (Google DeepMind’s computation paper)
Both Google DeepMind papers say their results do not threaten deployed RSA moduli of 2,048 bits or more, within the results and models they studied. (Computation paper; fan-factory paper)
