DeepMind's AI agents made old 1024-bit RSA cheaper to attack — time to retire the last of those keys

Google DeepMind says two of its AI agents, supervised by human researchers and working with cryptographers from UC San Diego and Inria, found ways to make attacks on old 1024-bit RSA keys cheaper. Modern 2048-bit and larger keys are not affected, the researchers say. If anything in your estate still signs or authenticates with 1024-bit RSA, this is a good reason to move it up your replacement list.

What happened, in plain English

RSA is one of the oldest and most widely used public-key encryption systems. It protects digital signatures, website certificates, VPN and SSH logins, email signing and much more. Its strength depends largely on key size, measured in bits. 1024-bit keys were standard twenty years ago. Today 2048 bits is the usual minimum, and the US National Institute of Standards and Technology (NIST) no longer approves 1024-bit keys for creating signatures.

In two working papers published in early November 2026, Google DeepMind described results obtained with AI agents — AI models that write code, run jobs and fix their own errors with little human input.

• Finding 1 — signatures. For some ways of using a 1024-bit key to sign data, the fixed formatting ("padding") around the signed data adds no real protection once an attacker controls about half of the signed block. In a test, the agents redid a known academic forgery computation with 3.5 times less computing power: 391 CPU core-years instead of 1,380. It still did not reveal the private key.
• Finding 2 — many keys at once. A theoretical method that would make factoring each additional 1024-bit key about 30 times cheaper than the previous best batch method, after an upfront cost about equal to factoring one key. It has not been built.

An analogy: the lock is the same, but someone found a faster way to copy one particular type of old key — and only if you let them practise on your key-cutting machine billions of times first.

Are you affected? What to do now

Most organisations have nothing urgent to do. No attack has been reported, nothing was released as a tool, and 2048-bit and larger RSA is not affected. The practical lesson is to finish retiring 1024-bit RSA, which standards bodies already asked for years ago.

Who should pay closer attention:

• Teams running hardware security modules (HSMs) or smart cards that still hold 1024-bit RSA signing keys and expose a "sign whatever you send me" interface to many applications or users.
• Owners of legacy and embedded systems (industrial equipment, old appliances, firmware signing, internal certificate authorities) that cannot easily change key size.
• Anyone with large fleets of 1024-bit keys, since Finding 2 is about making each extra key cheaper.

Checklist:

• Inventory key sizes. Look for 1024-bit RSA in TLS certificates, internal certificate authorities, SSH host and user keys, email-signing (DKIM) DNS records, VPN appliances, code- and firmware-signing keys, and HSM key stores. Certificate-management and vulnerability scanners usually report key length.
• Replace 1024-bit keys with RSA 2048 or larger, or an elliptic-curve alternative your systems support. Start with keys that sign things others trust (firmware, software, certificates).
• For HSM signing services: check which signing mechanisms applications can call. According to the paper, the exposed cases are raw RSA and PKCS#1 v1.5 signing where the caller supplies most of the signed bytes (PKCS#11 mechanisms CKM_RSA_X_509 and CKM_RSA_PKCS). Mechanisms where the device hashes the message itself (for example CKM_SHA256_RSA_PKCS) are outside the attack model. Prefer those, and restrict who can call signing functions.
• Watch query volume. The demonstrated forgery needed about 4 billion signing requests collected in advance. Rate limits and alerts on unusual signing volume on HSMs are cheap insurance.
• Ask suppliers whose products still ship 1024-bit RSA when they will move to longer keys, and record the answer in your risk register.
• Plan ahead. The researchers' own advice is to plan moves to stronger parameters well in advance. If you have a post-quantum migration plan, fold 1024-bit removal into it.

The expert view

What the signature result is. Forging an RSA signature without the private key means computing a modular root of a value the attacker chooses. The papers study the case where an attacker first gets many genuine signatures on inputs it picks (an "offline phase"), then must produce a root for a new target. The "affine" version restricts the attacker to inputs with a fixed part (the padding) and a small variable part. The proved result: once the variable part covers roughly the square root of the modulus — about 64 of 128 bytes at 1024 bits — the padding no longer makes the problem harder. Under PKCS#1 v1.5 with long caller-chosen data (up to 117 bytes), or a 64-byte digest, the attacker is in the easy regime. A 32-byte digest (SHA-256-sized) leaves a harder problem that the team did not run at this size, although, as SecurityWeek reports DeepMind's estimate, the new approach is in theory about 1,600 times better than the previous best method for that case at 1024 bits.

What it is not. It is not factoring and it does not recover the key. DeepMind cites 500,000 to 1 million core-years to factor a 1024-bit modulus; the first forged root cost about 0.04–0.08% of that. It does not apply where the application hashes before signing, which covers most well-built systems. Raw RSA (CKM_RSA_X_509) is not an approved signature scheme anyway.

What is new. The mathematics builds on known number-field-sieve work, and the 1024-bit run reproduces an existing academic computation more cheaply. The novelty is how it was done. Per the paper, a "supervisor" agent wrote the design, budgets and checks, and an "executor" agent wrote about 33,500 lines of new code, ran 336 distributed experiments and fixed failures — including a 32-bit integer overflow that first produced a wrong answer. A specialist sub-agent sped up one step. The human set the goal, approved irreversible steps and sent about 20 short messages, writing no code. Wall-clock time was about 3.2 days, against roughly five months for the earlier run, mainly because of parallelism (peaks around 300,000 CPU cores and 16 GPUs). The batch-factoring paper used one model to generate proofs and another to check them, with key steps machine-checked in the Lean proof assistant.

Why it matters. It fits a pattern our readers have seen all autumn: AI is shortening the time between "theoretically weaker" and "measured and demonstrated" — the same dynamic as AI-assisted vulnerability research, where Microsoft said finding bugs is no longer the hard part. Pushmeet Kohli, a vice president at Google DeepMind, put it this way, as quoted by SecurityWeek: "we cannot treat cryptographic hardness as a fixed assumption." For defenders, that argues for crypto agility — knowing where every key lives and being able to swap algorithms quickly.

What is still unknown. The papers do not name the AI models used. The batch method is an unbuilt estimate based on standard heuristic assumptions, and the authors make no claim about when it would beat a well-tuned implementation in practice. All estimates at 2048 bits are asymptotic, and the authors state their results do not threaten deployed 2048-bit and larger RSA today. The documents describe no coordinated disclosure process, likely because there is no single vendor to notify: the weakness is in old parameter choices, not a product.

Official sources

• Google DeepMind (working paper): Modular Roots from a Restricted Oracle: Faster Affine Roots and a 1024-bit Computation
• Google DeepMind (working paper, November 5, 2026): Fan Factories: Multiple Number Fields in Factorization Factories and Batch NFS
• Coverage: SecurityWeek — Google DeepMind's AI Agents Make 1024-Bit RSA Keys Cheaper to Attack (November 9, 2026)