DeepMind RSA-1024 Weaknesses: What Data Teams Should Fix
DeepMind's AI agents found two RSA-1024 weaknesses: 1,600x cheaper forgery in theory and 30x batch factoring. What it means and how to retire old 1024-bit keys.
Google DeepMind says its AI agents found two new weaknesses in 1024-bit RSA. It took weeks. One result makes forging signatures far cheaper in theory, and the other makes cracking a large batch of 1024-bit numbers cheaper for each one after the first.
Your bank's website isn't at risk. Modern systems use 2048 bits or more, which these results don't touch. But plenty of data stacks still run old 1024-bit RSA in quiet corners, and the cost of attacking it just dropped again. This guide explains the research in plain terms, then shows how to find and replace what you still run.
Disclosure and scope: Van Data Team builds data and AI systems for clients. We have no business ties to Google. We drafted this article with help from Anthropic's Claude, an AI model whose maker is linked to one of the factoring records below, and checked each claim against the sources linked here.
DeepMind's papers weren't public in full when we wrote this, so a few numbers come from news coverage. We say so each time and label our own math.
Key Takeaways
- The news: on November 6, 2026, DeepMind said AI agents, steered by people, found two weaknesses in 1024-bit RSA.
- Weakness one: a new way to forge signatures, about 1,600 times cheaper by DeepMind's estimate, when an attacker controls part of the signed data.
- Weakness two: a "fan factory" that makes each extra factoring about 30 times cheaper. Nobody has built one.
- Measured: the agents redid part of a recent attack in 391 CPU core-years, against 1,380 for the original team.
- Not affected: 2048 bits and up, says DeepMind.
- For data teams: find your remaining RSA-1024 this month and replace it.
RSA-1024 Weaknesses at a Glance
| Item | What was reported | Measured or estimated? |
|---|---|---|
| Announced | November 6, 2026, by Google DeepMind, in two working papers | Fact |
| Who | DeepMind's Dj Dvijotham and Abhradeep Thakurta, with Nadia Heninger and Emmanuel Thomé | Fact |
| Weakness 1 | Signature forgery about 1,600x cheaper when the attacker controls part of the signed data | Estimate |
| Weakness 2 | Batch factoring about 30x cheaper for each extra 1024-bit number | Estimate, not built |
| Rerun | 391 CPU core-years, against 1,380 in the original attack | Measured |
| Scope | 1024-bit RSA only; DeepMind says 2048-bit and up are not affected | DeepMind statement |
What DeepMind Found in RSA-1024
The work came out as two working papers, "Modular Roots from a Restricted Oracle" and "Fan Factories," published on November 5 and 6, 2026. DeepMind researchers Dj Dvijotham and Abhradeep Thakurta led it, Crypto Briefing reported. Two well-known cryptographers joined them: Nadia Heninger of UC San Diego and Emmanuel Thomé of Inria.
The AI did the heavy lifting. People set the goals.
- The agents proposed ideas, wrote code and ran tests.
- The humans chose the problem, steered the search and checked the results.
- The setting was isolated, and DeepMind says it never touched live systems.
The papers haven't been peer reviewed yet, which matters because the two biggest numbers in this story are estimates from math, not results from a real attack on a real system.
How RSA Works, in Plain Terms
RSA is one of the oldest public-key systems still in daily use. It rests on a simple bet: multiplying two huge primes is easy, but splitting the result back into those primes is extremely hard.
The big number you publish is public. The two primes are the secret. Anyone who can split, or factor, that public number can read what was sent to you and sign messages as you.
Length sets how hard the split is:
- 1024-bit RSA uses a number about 309 digits long.
- 2048-bit RSA uses one about 617 digits long.
- Each extra bit makes factoring harder, so the gap between the two is enormous in practice.
Weakness One: Forging Signatures With Less Help
The first paper builds on an attack from September 2026. A team from UC San Diego and Inria, including Heninger and Thomé, forged signatures for a 1024-bit RSA secret stored in a hardware security module, according to their preprint. They didn't factor anything. They used the device as a "signing oracle," asking it to sign about four billion chosen values.
That attack was costly. It took 1,380 CPU core-years over five calendar months, and the device had to sign raw values on request. After that setup, the team could forge any signature they liked, offline.
DeepMind's agents asked a harder question. What if the attacker controls only a small part of what gets signed, such as a 32-byte hash? They found a new method for that case, and by DeepMind's own estimate it beats the best known method by about 1,600 times for 1024-bit RSA.
Two caveats apply:
- It's an estimate. The 1,600x figure comes from math, not a timed attack.
- The setting is narrow. The attacker needs a way to get the target to sign data they partly choose.
Weakness Two: The "Fan Factory" for Batch Factoring
The second paper is about scale. Factoring one 1024-bit number is hugely expensive, and normally the second costs as much as the first. A "fan factory" changes that.
The idea is to pay a large setup cost once, about the price of one full factoring. After that, each extra 1024-bit number of the same size costs roughly 30 times less than the usual multi-target method, as Byteiota summed up the paper. The more targets an attacker has, the better the deal.
Here's what that could mean, using a simple model of our own. We assume the setup costs one factoring and each extra target costs one-thirtieth of one.
| Targets | Normal cost (one factoring each) | Fan factory cost (our math) | Saving |
|---|---|---|---|
| 1 | 1 | About 1.03 | None |
| 10 | 10 | About 1.3 | About 7.5x |
| 100 | 100 | About 4.3 | About 23x |
| 1,000 | 1,000 | About 34 | About 29x |
One target gains nothing. A thousand get close to the full 30x, which is why the threat lands hardest on big pools of old RSA, like DKIM records across thousands of domains.
And it's still theory. The paper itself says no fan factory has been built.
The Measured Result: 391 vs 1,380 Core-Years
One number in this story was actually measured. Two AI agents reran the main step of the September attack, finding what the paper calls the first root, with the same algorithm and settings. It took 391 CPU core-years, against 1,380 for the original team, Plain English reported.
- Compute: 391 CPU core-years, about 3.5 times less than the original 1,380.
- Human input: about 20 short messages from people, according to coverage.
- Wall-clock time: under four days, on a huge pool of machines.
This is an engineering gain, not a new attack. It shows AI agents can tune hard math code well, and it changes what an attack costs rather than what's possible.
What the AI Agents Did, and What Humans Did
The headline says "AI found weaknesses." The truth is more shared. Human experts picked the problem, set the limits and judged the results, while the agents wrote code, tested ideas fast and ran long jobs without a break.
That split is the real news. Cryptanalysis used to move at the pace of a few experts working through ideas by hand for years. Now agents can try dozens of paths at once.
It fits a pattern from this fall:
- September 3, 2026: Eric Lu of Cognition factored RSA-260, an 862-bit number, using Devin AI agents.
- September 19, 2026: Anthropic engineer Stephen Weis factored RSA-896 with help from Claude, using up to 2,048 GPUs for about 10 days, Tech Times reported.
- November 6, 2026: DeepMind's agents found new math, not just more speed.
The first two records mostly came from raw computing power, guided by AI. DeepMind's result is different. Its agents found new methods, and that's the shift worth watching as more labs point agents at old, hard math problems.
Is RSA-1024 Broken?
Not in the "anyone can read your traffic" sense. But it's been on borrowed time for over a decade:
- Nobody has shown a full, cheap break of 1024-bit RSA.
- Both new results are cost cuts on paper, and one hasn't been built.
- NIST stopped allowing it for new signatures at the end of 2013, under SP 800-131A.
- Well-funded attackers were thought able to factor it long before this week.
Each new result moves the cost down. What was "too expensive to attack" becomes "expensive" and then just "a budget line." If you still run it, the case for fixing it just got stronger, and waiting another year only makes the job bigger.
Is RSA-2048 Still Safe?
Yes. DeepMind says 2048 bits and above are not affected by these results. The public factoring record is 896 bits, and going from there to 2048 bits takes many orders of magnitude more work.
There's one nuance. The September preprint argues that if an attacker can get raw signatures from your device, RSA's real strength is 15 to 30 bits lower than factoring alone suggests. Its authors say even 4096-bit RSA falls short of 128-bit security in that model, and they see it as a reason to move away from RSA.
So 2048-bit RSA is safe from these attacks today. It isn't a forever answer. NIST's draft transition plan would deprecate 2048-bit RSA after 2030 and disallow RSA entirely after 2035, because of quantum computers.
Where RSA-1024 Still Hides in Data Stacks
Most teams don't create 1024-bit RSA today. They inherit it. A credential made in 2012 for a partner feed can still be running, untouched, because nothing broke.
| Place | Why 1024-bit RSA lingers | How to check |
|---|---|---|
| DKIM email signing | Set up once in DNS, then forgotten | Look up the DKIM record |
| SSH | Old servers and service accounts | Run ssh-keygen -l on each .pub file |
| SFTP partner feeds | Swapped years ago with a vendor | List entries in your SFTP tool or vault |
| Database and dashboard TLS | Self-signed certs on internal hosts | Read the cert with openssl |
| JWT signing (RS256) | Old auth services nobody touches | Read your JWKS endpoint |
| Hardware security modules | Made on older HSMs | Export the list from the HSM console |
| Code and file signing | Old build pipelines | Inspect the signing cert |
DKIM deserves a closer look:
- It's allowed: the email standard, RFC 8301, still lets signers use 1024 bits, and older domains often do.
- It's a big pool: a fan factory would make bulk attacks on those records cheaper.
- It's your name: a forged DKIM signature makes phishing mail look like it came from you.
How to Find RSA-1024 in Your Systems
You don't need special tools. These commands show the size for the most common cases. Run them only against systems you own.
Check a certificate file. Look for "Public-Key: (1024 bit)" in the output:
openssl x509 -in server.crt -noout -text | grep "Public-Key"
Check the certificate on a live database or web host:
echo | openssl s_client -connect db.internal:5432 -starttls postgres 2>/dev/null \
| openssl x509 -noout -text | grep "Public-Key"
Check SSH on a server. The first number in each line is the size in bits:
for f in /etc/ssh/ssh_host_*_key.pub ~/.ssh/*.pub; do ssh-keygen -l -f "$f"; done
Check a DKIM record, with your own selector and domain. A p= value about 216 characters long means 1024 bits; about 392 means 2048:
dig +short TXT selector1._domainkey.example.com
For a big estate, put these checks in a scheduled job and write the results to a table. Then track the weak count going down week by week, like any other data quality metric.
A 30-Day RSA-1024 Retirement Plan
You can clear most of it in a month. Here's a plan that works for a typical data platform:
- Week 1, inventory: run the checks above across hosts, DNS, vaults and HSMs, and record each item's owner, size, use and last rotation.
- Week 2, rank: fix signing first, plus anything facing the internet. DKIM, JWT and public TLS come before internal tools.
- Week 3, replace: issue new credentials, publish them next to the old ones and switch over. For partner SFTP, agree on a cutover date in writing.
- Week 4, remove and guard: delete the old ones, revoke old certificates and add a CI check that rejects anything under 2048 bits.
The last step is the one teams skip. Without a guardrail, 1024-bit RSA will be back the next time someone copies an old config.
What to Replace RSA-1024 With
| Use | Replace RSA-1024 with | Notes |
|---|---|---|
| SSH | Ed25519 | Fast and short, supported by OpenSSH since 2014 |
| TLS certificates | ECDSA P-256 or RSA 3072 | Both work with nearly every client |
| JWT signing | ES256, or RS256 at 3072 bits | Rotate through your JWKS endpoint |
| DKIM | RSA 2048 | Recommended by RFC 8301; a few DNS hosts need the record split |
| SFTP | Ed25519 or RSA 3072 | Agree on a cutover date with each partner |
| Long-lived signatures | RSA 3072 or more, plus a post-quantum plan | Data signed today may need to verify in 2040 |
Don't jump to the biggest size you can find. Huge RSA slows down handshakes and signing. Pick a modern option that fits the job, and keep the setting in your config, not in someone's head.
Plan for Post-Quantum While You're at It
Replacing old RSA is a good moment to look further ahead. A large enough quantum computer would break RSA and elliptic-curve cryptography of any size. Nobody has one yet. But data stolen today could be decrypted later.
NIST published its first post-quantum standards in 2024, and cloud providers are adding them now, as we covered in our guide to quantum-safe key import in Cloud KMS.
You don't need to switch everything this year. Your inventory from the 30-day plan is exactly the list you'll need for that move, so build it once and keep it current.
What to Watch Next
| When | What to watch |
|---|---|
| Coming months | Peer review and outside checks of the two working papers |
| Coming months | Whether anyone builds a working fan factory |
| 2026 and 2027 | New public factoring records after RSA-896 |
| 2030 | NIST's plan to deprecate 2048-bit RSA |
| 2035 | NIST's plan to disallow RSA and elliptic-curve cryptography entirely |
The big question is whether AI agents keep finding new math, or whether this was a one-off. If more results like this arrive, every rule of thumb about RSA length will need a fresh look sooner than planned.
RSA-1024: Our Take
This is a real result, and a narrow one. DeepMind didn't break the encryption that protects the web. It showed that AI agents, steered by experts, can find new attacks on an old standard in weeks.
That speed is the story. Crypto research has long assumed a better attack takes years of expert work. If agents shrink that to weeks, the safety margin on every aging system gets thinner, faster.
For data teams, the action is simple and overdue. Find every 1024-bit RSA credential you own and retire it. It's a month of work, and done well, it also gives you the full inventory you'll need when the post-quantum move arrives in earnest.
How Van Data Team Helps
We help teams keep data systems secure without slowing delivery:
- Certificate and credential audits across hosts, pipelines and DNS, through our system operations and maintenance service.
- Pipelines with security checks built in, such as CI rules that block weak RSA, via data pipeline development.
- AI agents for ops work, like scheduled scans and alerts, through AI agent development.
- Dashboards that track weak credentials and rotation dates for every owner, through agentic BI reporting.
For more on AI and security, see our guide to agentic AI security.
Still running old RSA you're not sure about? Get in touch and we'll help you map it, rank it and replace it without breaking a single partner feed.
AI Model Brief
The AI models worth knowing, once a week
What shipped, how it scores on independent benchmarks, what it costs per million tokens and what was deprecated, from the data behind our AI model benchmarks.
We use your address only to send the brief. See our privacy policy.
See this week’s brief
Founder of Van Data Team. Builds Vanaxity, the AI agent system for SEO, GEO, and AEO, and leads data engineering delivery for B2B teams.
About the authorArticle FAQ
Questions readers usually ask next.
These short answers clarify the practical follow-up questions that often come after the main article.
Need a similar system?
If this article maps to a workflow your team already operates, the next step is usually a scoped review of the system, constraints, and rollout path.
Consultation
Scope your next AI workflow.
Share the system and blockers. We will map fit, gaps, and the next step.







