DeepMind's 'Fan Factories' Paper: The Cost of Breaking Many 1024-bit RSA Keys, and a 1024-bit DKIM Key Check

On November 6, 2026 (US time), Google DeepMind announced that AI agents had helped find two weaknesses in 1024-bit RSA. This article covers only the one whose full text we could open and check: the batch-factoring paper "Fan Factories." It lowers the cost of each key when many keys of the same size have to be factored. At 1024 bits, after a precomputation that costs about as much as factoring one key, each further key comes out roughly 30 times cheaper than with the best previous per-key method (MNFS). That 30x is a theoretical estimate, not a measurement, and the paper sets apart, in a highlighted note under the abstract, that the results do not threaten cryptosystems deployed today on RSA at 2048 bits and above.

So nothing needs to change today. But the paper's target is "many 1024-bit keys of the same size," and DKIM, the RSA signature on outgoing mail, is exactly that kind of population. We looked up the DKIM key this site (kortress.com) uses for sending mail through Resend, and it is 1024-bit. Below: the number the paper moved, total cost for many keys recomputed from the paper's formula, what the estimate leaves out, the DKIM lookup and the two standards that disagree about it, reactions, and what this means for developers.

An exponent that had not moved since 1993

Factoring algorithms are compared by the constant c in the cost expression L[c]. A smaller c is faster; at 1024 bits, the paper notes, a change of 0.1 in c changes the cost estimate by a factor of about 23. The general number field sieve (GNFS), the standard method for integers without special form, has c ≈ 1.9230. Coppersmith's multiple number field sieve (MNFS) lowered that to 1.9019, and according to the paper that figure had stood since 1993.

For factoring many keys, Coppersmith also proposed a "factorization factory": do the work shared by all keys of one size once, then reuse it. The catch was that a precomputation as small as one ordinary factorization gave the factory no advantage at all. With that budget, the best cost per key had stayed at MNFS's 1.9019 since 1993.

Fan Factories gives each key its own "fan" of number fields, all tested against the shared precomputed data. With a precomputation budget of one GNFS run, the per-key exponent drops from 1.9019 to 1.7929. Figure 4 of the paper labels that stretch "no change for 33 years."

The last row matters most. With an unlimited precomputation budget, Coppersmith's 1993 factory is still optimal and fans add nothing. In the paper's words, this is an improvement for modest budgets, "not a new lower floor." What moved is the entry cost of a mass attack, not its ceiling.

The paper says the results "were obtained with a two-agent AI harness": one model generated proofs and a second verified them, and the algebraic identities behind the closed-form results were machine-checked in the Lean 4 proof assistant. It does not name the models. The authors include Google DeepMind researchers and the cryptographers Nadia Heninger (UC San Diego and Inria) and Emmanuel Thomé (Inria); the document is a working paper dated November 5, 2026.

Total cost by number of keys

The 30x compares one additional key after the precomputation is already paid for. Whether an attacker actually comes out ahead depends on how many keys there are, once the precomputation is counted. Section 4.1 of the paper gives the total for M keys at 1024 bits as 1 + M/58.5 GNFS runs for the fan factory and M/1.94 for MNFS. Figure 1 plugs values of M into those formulas.

For a single key the fan factory costs about twice as much as MNFS (1.02 vs. 0.52). From three keys it is cheaper, and at 100 keys it needs the equivalent of 2.71 GNFS runs against 51.5 for MNFS. The paper itself says the fan factory "is cheaper for every M ≥ 3."

At 2048 bits the per-key ratio grows to 1/240 of a GNFS run, 99 times less than MNFS (Table 2 of the paper). Keys of 2048 bits stay safe anyway because the precomputation alone costs as much as factoring one such key, about 2^117 operations at leading order. A better ratio does not help if you cannot afford the entry ticket.

What the estimate leaves out

Figure 1 is not a runtime prediction. The paper lists four constraints itself:

• Every figure is a leading-order estimate with the o(1) terms set to zero. The hidden factors differ between algorithms "and can be large," so these are "not a prediction of running times."
• No fan factory has been implemented, and the authors make no claim about the size at which one would overtake a well-tuned number field sieve.
• Memory is a second obstacle. At a budget of one GNFS run, the stored table holds about 2^75 pairs at 1024 bits.
• The results rest on the standard heuristics used in number field sieve analyses.

There is no benchmark in the usual sense. Every number is the authors' own theoretical calculation. The only independent check we found is frank chu (see Reactions) recomputing the 1/58 and 30x from the paper's constants; we found no implementation or measurement.

DKIM key lookup for kortress.com

DKIM signs outgoing mail with RSA, and receivers check the signature against a public key published in DNS. Mail-sending services issue keys of one size to every customer domain, which makes DKIM a large population of same-size keys. So we started with this site's own key.

A DKIM public key that begins with MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ is 1024-bit RSA; a 2048-bit key begins with MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA. If you know your selector, the same check takes two steps:

curl -s "https://dns.google/resolve?name=<selector>._domainkey.<your-domain>&type=TXT"
# wrap the p= value in a PEM header, then
openssl pkey -pubin -in key.pem -noout -text | head -1

Two standards for 1024-bit DKIM

The 1024-bit key is not a misconfiguration; it is Resend's policy. Resend's documentation says it "signs outbound mail with 1024-bit DKIM keys" and "does not support 2048-bit DKIM keys," that the key length cannot be changed, and that it does not rotate or regenerate keys on request. It cites RFC 8301 Section 3.2 as recommending "signers use keys of at least 1024 bits."

The RFC says something slightly different. Signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits." In other words, 1024 bits is the floor and 2048 bits is the recommendation. Resend's summary carries over only the first sentence.

The benefits Resend lists for 1024-bit keys (faster signing and verification, no DNS TXT length trouble, meeting the bulk-sender rules of major mailbox providers) are real, and this paper does not change the cost of breaking any single 1024-bit DKIM key. What it changes is the theoretical picture of attacking the whole population of 1024-bit keys at once.

Reactions

A Hacker News submission of the X announcement by co-author Pushmeet Kohli (Google DeepMind) went up on November 7 (UTC); when we checked on November 9 it had 3 points and no comments (https://news.ycombinator.com/item?id=50401254). There has been no substantive discussion there yet.

On the skeptical side, developer frank chu wrote "1,600x is arithmetic, not an attack: I checked DeepMind RSA" on DEV Community (https://dev.to/frankchu/1600x-is-arithmetic-not-an-attack-i-checked-deepmind-rsa-12di). He recomputed the ratios from the paper's constants, got "NFS/fan: 58.3" and "MNFS/fan: 30.2," and called that "a genuine check" but no more than that. He also split the announced numbers into measured and estimated columns, listed "Fan factories built: 0," and advised readers to "treat them as directions, not arrival times." For the companion signature-forgery paper, he singled out what was actually run: the agents reproduced an earlier attack in 391 CPU core-years instead of the original 1,380. We could not find a public copy of that paper at the time of writing, so this article does not cover it.

We found no independent supportive reaction. So far the positive reading has come only from DeepMind and the paper's authors.

What changes for developers in Korea

Nothing changes for TLS certificates, code signing or login tokens that use RSA at 2048 bits or more. The paper says so, and the arithmetic above backs it up.

The places to look are where 1024-bit RSA still survives. DKIM mail keys are the obvious one; old HSM configurations and firmware-signing keys also look worth checking. The reason is not that an attack became practical. It is that research showing per-key cost falling as the number of same-size keys grows took its first step in 33 years, with AI help. The authors themselves say such analyses "help to judge how much protection a key size gives when many keys of that size are in use."

If your mail goes through a service that, like Resend, does not offer 2048-bit DKIM, you cannot change the key length yourself. The realistic options appear to be switching services or asking the provider for 2048-bit support. Finance and public-sector services with strict anti-spoofing policies may want to confirm that their provider's default matches the RFC's 2048-bit recommendation.

Limitations

What generalizes is the direction (the more same-size 1024-bit keys in use, the thinner the theoretical margin), not the 30x itself.

Sources

• Google DeepMind, Fan Factories: Multiple Number Fields in Factorization Factories and Batch NFS (working paper, 2026-11-05): https://storage.googleapis.com/deepmind-media/papers/Fan_Factories_Multiple_Number_Fields_in_Factorization_Factories_and_Batch_NFS.pdf
• IETF, RFC 8301 Section 3.2, Key Sizes: https://www.rfc-editor.org/rfc/rfc8301.txt
• Resend, Do You Need 2048-bit DKIM?: https://resend.com/docs/knowledge-base/do-i-need-2048-dkim.md
• Hacker News, DeepMind AI agents find two weaknesses in legacy 1024-bit RSA cryptosystems: https://news.ycombinator.com/item?id=50401254
• frank chu, 1,600x is arithmetic, not an attack: I checked DeepMind RSA (DEV Community): https://dev.to/frankchu/1600x-is-arithmetic-not-an-attack-i-checked-deepmind-rsa-12di