DeepMind’s AI agents found two weaknesses in 1024-bit RSA. What to check

What DeepMind announced

On November 6, 2026, Pushmeet Kohli of Google DeepMind published “Advancing the frontier of cryptanalysis”, on two new attacks against RSA with 1024-bit keys. “Our team used AI agents, guided by human supervision,” he wrote. The work was led by DeepMind’s Dj Dvijotham and Abhradeep Thakurta, with two cryptographers from outside the company, Nadia Heninger of UC San Diego and Inria and Emmanuel Thomé of Inria. It comes as two working papers: one on forging signatures and one on factoring many keys at once.

RSA is the public-key system behind many signatures and certificates, and its security rests on how hard it is to factor a large number. 1024 bits is its old key size. NIST’s SP 800-131A already says keys that weak “shall not be used to generate digital signatures,” and allows 1024-bit RSA only for “legacy use” in checking old ones.

What it means for your keys

If your RSA keys are 2048 bits or longer, nothing changes. Kohli writes that modern protocols, “which almost universally use 2048-bit or larger keys, remain secure,” and both papers open with nearly the same warning, in the batch paper’s words: “Our results do not threaten deployed cryptosystems today that are based on 2048-bit and larger RSA.” Elliptic-curve keys, such as Ed25519 SSH keys and ECDSA certificates, aren’t RSA, and the papers don’t concern them.

If you still have 1024-bit RSA keys, their margin got thinner, and these are the places to look:

• Email. DKIM, which signs your domain’s outgoing mail, still allows them. RFC 8301 says “Signers MUST use RSA keys of at least 1024 bits” and “SHOULD use RSA keys of at least 2048 bits.” Google Workspace offers a 1024-bit key “If your domain host doesn’t support 2048-bit keys.”
• SSH. For RSA, ssh-keygen’s “minimum size is 1024 bits and the default is 3072 bits,” its manual says, and OpenSSH’s server accepts 1024-bit keys unless told otherwise. GitHub has refused new RSA keys under 3072 bits since October 14, 2026, but keys added before then keep working.
• Old certificates and devices. Internal certificates and hardware that signs with a key set years ago are the other places a 1024-bit key can still be in use.

The two results

	Forging signatures	Factoring many keys
What the attacker needs	Billions of signing requests to a device holding the key	Many 1024-bit keys, and work up front as costly as factoring one
What the attacker gets	Signatures on new messages, without the key	The private keys
The headline figure	“Roughly 1,600x” better, in theory, when the requester supplies a 32-byte digest	About 30 times cheaper per extra key, in theory
What was actually run	A known attack, redone in 391 CPU core-years instead of 1,380	Nothing: “no fan factory has been implemented”
2048-bit keys	Not threatened	Not threatened

Forging signatures. The attack, from Joux, Naccache and Thomé in 2007, assumes someone gets temporary access to a device that signs with the key, such as a hardware security module, and sends it billions of requests of their own choosing. Afterward, without the device, they can sign new messages as if they had the key. In a paper posted in September, Heninger, Thomé and three UC San Diego colleagues reported running it at 1024 bits, in 1,380 CPU core-years over five calendar months.

DeepMind’s paper adds two findings. The standard PKCS#1 v1.5 padding stops making the attack harder once the requester chooses about half of the 128-byte block: 65 bytes or more, or a 64-byte SHA-512 digest. And when the requester supplies only a 32-byte SHA-256 digest, a new algorithm lowers the cost. That is Kohli’s “roughly 1,600x.” The paper says of it: “we did not run it at this size.”

The paper sets out the limits too. These attacks “do not recover the key.” They need “direct calls to the signing interface with inputs of the caller’s choice, rather than calls through an application that hashes the message before signing,” about 4 billion of them. Devices that hash the message themselves, such as the PKCS#11 mechanism CKM_SHA256_RSA_PKCS, are “outside both oracle models.”

Factoring many keys. Factoring one 1024-bit key outright is estimated at 500,000 to 1,000,000 CPU core-years, the signature paper notes. When many keys of one size must be factored, some of the work can be shared. With shared work costing about as much as one factorization, the best cost for each further key had stood since 1993, with Coppersmith’s multiple number field sieve. DeepMind’s “fan factory” gives each key its own family of number fields. At 1024 bits, each further key would then cost about 1/58 of a factorization, “30 times less than with MNFS.” For a single key, “Nothing changes,” and for keys factored together with no shared precomputation, the gain is at most 1.75 times.

These are formulas, not timings. The paper calls its figures “not a prediction of running times,” says “no fan factory has been implemented,” and notes that the shared table would hold about 2^75 entries at 1024 bits.

What the AI agents did

The signature paper’s 1024-bit run was done by two language-model agents: a supervisor, “Model A,” which wrote the design, set the checks each stage had to pass and audited the results, and an executor, “Model B,” which wrote the code, ran the jobs and fixed what failed. They wrote about 33,500 lines of code, mostly C++, CUDA and Python, ran 336 distributed experiments on up to 300,000 CPU cores and 16 GPUs, and went from the start of the design to a verified result in 3 days and 22 hours. Along the way they found a 32-bit index overflow that had made the first computed root wrong, and fixed it.

The human researcher chose the problem, approved the steps that couldn’t be undone, and sent about 20 messages, “mostly approvals such as ‘follow your recommendation’ and ‘continue’.” In the paper’s words: “The researcher wrote no code, launched no job and diagnosed no fault.”

The run used the same algorithm, polynomials and bounds as September’s study and took 391 CPU core-years instead of 1,380. The paper is plain that “the factor of 3.5 is one of implementation and execution, not of algorithms”: faster code and cheaper steps within the same method, not new mathematics. More machines are why it took days rather than months. The new mathematics is in the estimates. For the batch paper, “one model generated the proofs, and a second model verified them,” and its algebra was machine-checked in Lean 4. Kohli’s conclusion: “we cannot treat cryptographic hardness as a fixed assumption.”

How to find 1024-bit keys

The SSH keys on your computer. The first number on each line is the key’s size in bits:

for f in ~/.ssh/*.pub; do ssh-keygen -l -f "$f"; done

On a server, ssh-keygen -l -f ~/.ssh/authorized_keys lists every key allowed to log in.

A website’s certificate, with your domain in place of example.com:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep "Public-Key"

Your domain’s DKIM key. Find the selector in the s= tag of the DKIM-Signature header on an email you sent, and put it in place of selector:

dig +short TXT selector._domainkey.example.com | tr -d '" \n' | sed -E 's/^(.*;)?p=//; s/;.*//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | grep "Public-Key"

As a shortcut, a p= value that starts MIGfMA0 is a 1024-bit key, and one that starts MIIBIjAN is 2048 bits.

What to do

1. Replace 1024-bit SSH keys. ssh-keygen -t ed25519 makes a new key. Add it wherever the old one was, then remove the old one from GitHub and from authorized_keys. On servers you run, RequiredRSASize 2048 in sshd_config refuses smaller RSA keys; OpenSSH’s default is 1024.
2. Move DKIM to 2048 bits. Generate a 2048-bit key under a new selector at your email provider, publish it, switch signing to it, and remove the old record once mail signed with it has been delivered. Google’s own page: “If you previously used a 1024-bit key, you can switch to a 2048-bit key if your domain provider supports them.” Some DNS hosts split a 2048-bit key into several quoted strings; the dig command above joins them.
3. Retire 1024-bit certificates and device keys. Where a device has to keep an old key for now, the forgery paper’s attacks need raw RSA or PKCS#1 v1.5 signing of data the requester supplies; mechanisms that hash the message inside the device are outside them.
4. Leave 2048-bit and larger keys alone. Nothing in either paper is a reason to rotate them.

What hasn’t been said

• Which models. Neither paper names the models behind “Model A” and “Model B,” or the two that wrote and checked the proofs. Kohli’s article says only “AI agents.”
• Whether it holds up. Both papers are labeled “Working Paper,” and we found no outside reproduction of either by November 8.
• What the new methods really cost. The 1,600x and 30x figures come from formulas. Neither new algorithm has been run, and the batch paper makes “no claim about the size at which it would overtake a well-tuned implementation of the number field sieve.”
• The code. Neither paper links its code, or the “full version” each cites for its complete proofs.
• Real targets. Neither paper names a deployed system that exposes the signing interface the forgery attack needs.