AI Agents Just Made 1024-Bit RSA Cheaper to Attack: The Problem Isn't the Math, It's the Keys Nobody Remembers
AI Agents Just Made 1024-Bit RSA Cheaper to Attack: The Problem Isn't the Math, It's the Keys Nobody Remembers
DeepMind's human-guided agents found two new weaknesses in legacy 1024-bit RSA, and that turns a long-postponed crypto cleanup into an inventory problem that AI will keep making more urgent.
What was announced
On 6 November, Google DeepMind said that AI agents, guided by human researchers, had found two new weaknesses in 1024-bit RSA. The work was led by DeepMind researchers with collaborators from the University of California San Diego and France's Inria. DeepMind's Chief Scientist Pushmeet Kohli announced it publicly, saying the results show why cryptographic assumptions need to be reassessed regularly as AI gets better at advanced mathematics.
The two findings, as described by DeepMind and in reporting on the announcement:
- Signature forgery through padding. Once an attacker controls about half or more of the data block being signed, the padding adds almost no extra protection, and forging a signature becomes roughly as hard as attacking unpadded "textbook" RSA. In a more realistic setting, where the attacker controls only a small part of the block (the example given is a 32-byte fingerprint), the agents found an algorithm that in theory improves on the best previous attack by about 1,600 times for 1024-bit keys.
- Batch factoring. A new method for factoring many keys at once lowers the average cost of each additional 1024-bit key by about 30 times compared with earlier batch techniques.
Two caveats matter. First, the 1,600x and 30x figures are theoretical estimates of how the cost scales, not measured attacks. The hands-on part was a sandbox test against a 1024-bit benchmark key that academics had already broken: the agent-written code reproduced the known forgery with about 3.5 times less CPU time. Second, 2048-bit and larger keys are not affected. Nobody has "broken RSA".
Why this is still a big deal
1024-bit RSA was supposed to be gone years ago. NIST deprecated it for new signatures more than a decade ago, and browsers stopped trusting 1024-bit certificate chains around the same time. Yet it never really left. It hangs on wherever cryptography was set once and then forgotten:
- Firmware signing keys and secure-boot chains on embedded and industrial devices built in the early 2010s.
- Old SSH host keys, and HSMs or smart cards that only support short keys.
- Long-lived code-signing and document-signing keys in archives that still need to verify.
- DKIM keys for email domains, where 1024-bit was the default for years and many domains never rotated.
- Internal PKIs, VPN appliances and vendor products whose defaults nobody checked.
The usual reasoning has been that factoring one 1024-bit modulus is still very expensive, so the risk is fine. Both findings attack that reasoning from different directions.
The batch result changes the economics for attackers who want many keys instead of one. Batch factoring is exactly what a well-funded adversary with a big list of collected public keys would do. Making each extra key about 30 times cheaper turns a pile of legacy keys into a much better target.
The signature result hits a different assumption, that padding makes up for a short modulus. Wherever an attacker can influence most of what gets signed, the margin turns out to be much thinner than people thought.
The more important story: AI as a cryptanalyst
The individual numbers matter less than how they were produced. Earlier this month, OpenAI described an automated run that turned hundreds of Linux kernel bugs into working local-root exploits. Now DeepMind shows agents helping to push forward the mathematics of a public-key algorithm that has been studied for nearly 50 years.
DeepMind is careful to call this human-guided research, not autonomous discovery, and that framing deserves respect. Still, the direction is clear. The rate at which "theoretical weakness" becomes "practical attack" has always depended on how many expert researcher-hours went into a problem. AI agents add researcher-hours cheaply, so the safety margins we set using history ("this took 15 years to get cheaper, so we have time") are now less reliable.
There is a defensive point too. The same kind of work tells defenders which margins are thinner than they believed, and it did so in public, against a key size that should already be retired. That is the best case. The worse case is that well-resourced groups reach similar results quietly.
What this is not
To keep it in proportion:
- Your TLS sessions using modern 2048-bit RSA or elliptic-curve keys are not suddenly at risk from this work.
- There is no new practical attack tool here, and the published results are about cost estimates and algorithms, not a ready-made exploit.
- This is unrelated to quantum computing. Post-quantum migration is a separate, longer-term programme, though it needs the same groundwork: knowing where your cryptography lives.
Practical takeaways
The useful response is an inventory, not panic.
- Find your 1024-bit keys. Scan certificates, SSH host keys, code-signing and firmware-signing keys, and DKIM records. For example, to check a key's size:
# Certificate or public key size
openssl x509 -in cert.pem -noout -text | grep "Public-Key"
# SSH host keys (prints bit length first)
for k in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$k"; done
# DKIM: fetch the public key record for a selector, then check its length
dig +short TXT selector._domainkey.example.com- Prioritise signing keys over encryption keys. The signature result is the new part. Firmware, boot-chain and document-signing keys where an attacker can shape the signed content should be the first to move to RSA-3072+, ECDSA or Ed25519.
- Rotate DKIM to 2048-bit. It is cheap, low risk and very often overlooked.
- Ask vendors directly. For embedded devices, appliances and HSMs, ask what key sizes are used for firmware signing and update verification, and whether they can be changed.
- Treat crypto margins as moving targets. Add key sizes and algorithms to your regular risk reviews and build crypto agility (the ability to swap algorithms without redesigning a system) into new projects. The same inventory will serve your post-quantum plan.
- Retire, don't just document. "Legacy, accepted risk" was a reasonable label when the cost of attack was stable. With AI pushing cryptanalysis forward, that risk acceptance should come with an expiry date.
