DeepMind AI RSA-1024 Weakness Explained + Key Check Guide

Google DeepMind says its AI agents, working with expert cryptanalysts, found two new weaknesses in old 1024-bit RSA. The work was shared on November 6, 2026, in two working papers.

The headline sounds scary, but the scope is narrow. DeepMind’s own paper says the results do not threaten RSA-2048 or larger keys, which is what modern systems use.

Below I explain what was found in plain English, then show you how to check every SSH key, TLS certificate and GPG key you own in a few minutes.

TLDR

What: DeepMind AI agents helped find a faster signature forgery method and a cheaper way to factor many 1024-bit RSA keys.
Numbers: about 1,600x better on one signature case (theoretical) and about 30x cheaper per extra key in a “factory” setting.
Who is safe: RSA-2048 and larger, plus Ed25519 and ECDSA keys, are not affected.
Who should act: anyone still running 1024-bit RSA in SSH, TLS, GPG, DKIM or DNSSEC.
Fix: check sizes with ssh-keygen -l and openssl, then replace 1024-bit keys with Ed25519, ECDSA or RSA 3072+.

What DeepMind Announced

DeepMind Chief Scientist Pushmeet Kohli announced the work on X on November 6, 2026. The research was led by Dj Dvijotham and Abhradeep Thakurta, with well-known cryptographers Nadia Heninger (UC San Diego and Inria) and Emmanuel Thomé (Inria).

Two working papers came out on November 5 and 6. They are titled “Modular Roots from a Restricted Oracle” and “Fan Factories: Multiple Number Fields in Factorization Factories and Batch NFS.” Neither has been peer reviewed yet.

How the AI was used

The team used a two-agent setup. One model generated the math proofs, and a second model checked them.

The key identities were then machine-checked in Lean 4, a proof language where a computer confirms each step. Human cryptanalysts guided the direction and reviewed the results.

Note: This is not an AI “hacking” live systems. All testing ran in an isolated sandbox against a 1024-bit key that researchers had already broken in an earlier academic study.

Weakness 1: Forging 1024-Bit RSA Signatures

An RSA signature proves that a message came from the key owner. Before signing, the message is “padded” with extra structured data to make forgery hard.

The first paper looks at a setting where an attacker can get a signer, such as a hardware security module, to sign data they partly control. That signer is called an “oracle.”

Big control: once an attacker controls roughly half the signed block or more, the padding adds almost no extra protection.
Sandbox test: on the already-solved benchmark key, the AI-built method used 3.5x less CPU time than the earlier record. That was under a thousandth of the work needed to factor the key itself.
Small control: even when the attacker controls only a 32-byte fingerprint, a new algorithm is estimated to beat the previous best method by about 1,600x for 1024-bit keys. This number is theoretical.

Reports say the reproduction ran for 3.2 days on up to 300,000 CPU cores and 16 GPUs, using 391 CPU core-years. The earlier run took about five months.

Weakness 2: Factoring Many 1024-Bit Keys at Once

The second paper, “Fan Factories,” is about breaking lots of RSA keys of the same size. It improves an idea called a “factorization factory,” where you do a big one-time setup and then factor each new key more cheaply.

The trick is to give each target number its own family, or “fan,” of number fields. All of them share one common side of the number field sieve, the standard tool for factoring big numbers.

Setting (1024-bit keys)	Claimed result	Compared with
Factory mode, after setup	Each extra key costs about 1/58 of one normal factoring run	General number field sieve (GNFS)
Factory mode, after setup	About 30x cheaper per extra key	Best previous factory method (MNFS)
Break-even point	3 or more keys are cheaper, counting the setup	MNFS
Batch mode, no setup	At most about 1.75x gain	Earlier batch methods

The paper is careful here. These are leading-order estimates, no fan factory has been built yet, and memory use is a real obstacle.

What This Does Not Mean

The “Fan Factories” paper states it plainly: “Our results do not threaten deployed cryptosystems today that are based on 2048-bit and larger RSA.”

Not a break of RSA: RSA itself still works. The gains apply to a key size experts have called weak for over a decade.
Not a quantum attack: this is classical math on normal computers.
Not a live exploit: no real-world system was attacked, and the biggest number is a theoretical estimate.
Not cheap: the setup step alone is about as costly as factoring one 1024-bit key.

Why it still matters

Two trends meet here. In September 2026, Anthropic’s Stephen Weis reported factoring the RSA-896 challenge number with help from Claude and up to 2,048 GPUs in about 10 days.

Now AI agents are also finding better math. DeepMind’s framing is that “cryptographic hardness can no longer be treated as a fixed, slowly-eroding assumption.”

On top of that, NIST published its final IR 8547 transition plan on October 27, 2026. It deprecates 112-bit RSA, which includes RSA-2048, after 2030 and disallows it after 2035, mainly because of future quantum computers.

Who Still Uses 1024-Bit RSA

Public TLS certificates moved to 2048-bit keys years ago, so most websites are fine. The risk sits in older and quieter places.

DNSSEC: a Sectigo podcast in October 2026 cited figures that about 89% of top-level domain zone signing keys still used RSA-1024.
DKIM email signing: the same source said about a third of domains in a small sample used 1024-bit DKIM keys.
Old SSH keys: keys made before about 2015 may still be 1024-bit RSA or DSA.
Old GPG keys: many long-lived keys from the 2000s are rsa1024 or dsa1024.
Internal systems: old routers, printers, VPNs, HSMs and private certificate authorities.

Warning: Signature forgery is the main concern for DNSSEC and DKIM. A forged DKIM signature could make a phishing email look like it came from your domain.

How to Check Your Key Sizes

These commands work on macOS, Linux and Windows with Git Bash or WSL. They only read keys, so they are safe to run.

Check your personal SSH keys. List the size of every public key in your SSH folder:
```
for f in ~/.ssh/*.pub; do ssh-keygen -l -f "$f"; done
```
The first number is the bit size. A line like 1024 SHA256:... (RSA) needs replacing. Ed25519 shows 256 ... (ED25519), which is fine.
Check keys allowed on a server. Run this on the server to see every key in authorized_keys:
```
ssh-keygen -l -f ~/.ssh/authorized_keys
```
Check a server’s SSH host keys. On the server itself:
```
for f in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -l -f "$f"; done
```
From your laptop, you can check a remote host with ssh-keyscan example.com | ssh-keygen -l -f -.
Check a live website’s TLS certificate. Replace example.com with your domain:
```
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep "Public-Key"
```
You want Public-Key: (2048 bit) or more for RSA, or (256 bit) for an EC key.

Check a certificate or key file. For a file on disk:

openssl x509 -in cert.pem -noout -text | grep "Public-Key"
openssl pkey -in private.key -noout -text | head -1

Check your GPG keys. List your keys with their algorithm:
```
gpg --list-keys --keyid-format long
gpg --list-secret-keys --keyid-format long
```
Look at each pub and sub line. rsa1024 or dsa1024 should be replaced. rsa3072, rsa4096 and ed25519 are fine.
Check your DKIM key. Use your DKIM selector (often “default”, “google” or “selector1”):
```
dig +short TXT selector1._domainkey.example.com
```
In the p= value, a 1024-bit key usually starts with MIGf. A 2048-bit key usually starts with MIIBIj.

Tip: Paste the output of these commands into a simple sheet with “key, where used, size, owner.” That inventory is the hardest part, and it pays off again when you move to post-quantum keys.

How to Upgrade Weak Keys

Here is what to replace 1024-bit RSA with in each place. When in doubt, pick the first choice in the table.

Where	Best choice	Safe fallback	Command to start
SSH user key	Ed25519	RSA 3072 or 4096	`ssh-keygen -t ed25519`
TLS certificate	ECDSA P-256	RSA 2048 or 3072	`openssl req -new -newkey rsa:3072`
GPG key	Ed25519 (ECC)	RSA 3072 or 4096	`gpg --full-generate-key`
DKIM	RSA 2048	Ed25519 alongside RSA	Your email provider’s admin panel
DNSSEC	ECDSA P-256 (algorithm 13)	RSA 2048	Your DNS host’s DNSSEC settings

Replace an SSH key

Make a new key. Run ssh-keygen -t ed25519 -C "you@example.com" and set a passphrase.
Add it to each server. Run ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server, or paste the public key into GitHub, GitLab or your cloud console.
Test it. Log in with ssh -i ~/.ssh/id_ed25519 user@server before you remove anything.
Remove the old key. Delete the 1024-bit line from ~/.ssh/authorized_keys on each server and from your Git host.

Replace a TLS certificate

If you use Let’s Encrypt, you are already fine: it does not issue certificates for 1024-bit RSA keys, and certbot 2.0 and later create ECDSA keys by default.

For a paid certificate, create a new key and request with openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr, then reissue through your certificate authority.

Replace a GPG key

Run gpg --full-generate-key and choose ECC (Ed25519) or RSA 4096. Sign the new key with the old one, publish it, and then revoke the old key with gpg --gen-revoke.

For DKIM and DNSSEC, change keys through your email or DNS provider. Google Workspace and Microsoft 365 both let admins generate 2048-bit DKIM keys in their admin consoles.

My Take

This is a real result, but it is not a reason to panic. It confirms what experts have said for years: 1024-bit RSA should be gone.

The more interesting part is the method. AI agents wrote proofs, other agents checked them, and Lean 4 verified the math, all guided by top human cryptographers.

That pattern will keep chipping away at old assumptions. So use this news as a nudge to clean up your keys now, while it is a 10-minute job and not an emergency.

AI is changing security work from both sides. For the defender view, see my guide to GPT-6 Cyber, OpenAI’s security model, and for checked AI output, my piece on Anthropic FlashProve.

The November 2026 AI model leaderboard shows which models lead on reasoning right now.

Troubleshooting Key Checks: Common Problems and Fixes

“is not a public key file”: you pointed ssh-keygen -l at a private key without a matching .pub file. Point it at the .pub file, or run ssh-keygen -y -f ~/.ssh/id_rsa to rebuild it.
openssl s_client hangs: it is waiting for input. Keep the </dev/null part, or press Ctrl+C after the output appears.
Wrong certificate shows up: the server hosts many sites. Always include -servername yourdomain.com so you get the right one.
“command not found: openssl” on Windows: use Git Bash or WSL, or install OpenSSL. Windows 10 and 11 include ssh-keygen in OpenSSH Client.
GPG shows only an ID, not the algorithm: add --keyid-format long, or update to GnuPG 2.2 or newer.
Old servers reject your Ed25519 key: very old OpenSSH builds lack Ed25519 support. Use an RSA 3072 key for that one host, and plan to update it.
dig returns nothing for DKIM: the selector name is wrong. Open the raw headers of an email you sent and read the s= value in the DKIM-Signature line.

Frequently Asked Questions

Did Google DeepMind break RSA encryption?

No. DeepMind’s AI agents helped find two faster attack methods against legacy 1024-bit RSA. The paper says RSA-2048 and larger keys are not threatened.

Is RSA-2048 still safe in 2026?

Yes, for now. NIST’s final IR 8547 plan deprecates RSA-2048 after 2030 and disallows it after 2035, so plan a move to post-quantum options over time.

What is the 1,600x figure?

It is a theoretical estimate for forging a 1024-bit RSA signature when the attacker controls a 32-byte fingerprint. It is compared with the previous best known method, not a demonstrated live attack.

How do I check my SSH key size?

Run ssh-keygen -l -f ~/.ssh/id_rsa.pub. The first number in the output is the key size in bits.

How do I check a website’s certificate key size?

Run openssl s_client against the site, pipe it into openssl x509 -noout -text, and look for the “Public-Key” line.

Should I use Ed25519 or RSA 4096 for SSH?

Ed25519 is the usual choice today because it is short, fast and strong. Use RSA 3072 or 4096 only for old systems that do not support Ed25519.

Are the DeepMind papers peer reviewed?

Not yet. Both are working papers released on November 5 and 6, 2026, though key proofs were machine-checked in Lean 4.

DeepMind AI Finds 2 Weaknesses in 1024-Bit RSA: What It Means and How to Check Your Keys