On Saturday, Stephen A. Weis announced that he had factored RSA-896, a 270-digit RSA challenge number, with Claude used to port CADO-NFS to run on GPUs. Before writing a word of this, we did the one check anybody can do: we multiplied his published p by his published q. The result is exactly the published modulus, 896 bits, two 448-bit primes. Real, and trivially verifiable, which is more than most cryptography headlines manage.
RSA-896 is not the story, though. What is still deployed is, so we went looking in the Irish estate. We swept 36 Irish domains for published DKIM keys across 32 common selectors. Thirty-one publish at least one key. Of the 110 keys we found, 47 are 1024-bit: 43%, spread across 27 of those 31 domains. Almost none of it was a decision anybody made.
TL;DR
- RSA-896 was factored on 19 September 2026 using roughly 30 GPU-years of scavenged idle compute. It does not break RSA-2048; the narrower claim is that RSA-1024 is “vulnerable to many actors with data center-level fleets of GPUs”.
- We swept 36 Irish domains across 32 DKIM selectors: 110 published keys, 47 of them 1024-bit, across 27 of the 31 domains publishing anything at all.
- Nobody chose those key sizes. Microsoft 365 still creates 1024-bit DKIM keys by default, and its rotation command upgrades only the selector that is not currently signing, so the job takes two runs four days apart. Three domains in our sample stopped exactly halfway.
- A rotating key pair is only as strong as its weaker half. RFC 8301 forbids verifiers from rejecting a 1024-bit signature, so half an upgrade buys close to nothing.
What actually happened, and what it does not mean
Weis’s write-up is three paragraphs long and promises more detail later, so we will attribute rather than assert. He describes porting CADO-NFS to GPUs with Claude’s help and running a fleet of up to 2,048 GPUs as a low-priority job in the unused gaps between other jobs at Anthropic: ten days of wall-clock, about 30 GPU-years of compute. His caveats are refreshingly flat: the work “did not meaningfully improve the runtime” of the General Number Field Sieve and “does not impact the security of deployed RSA-2048 keys”. What it does demonstrate, he argues, is that “RSA-1024 keys are vulnerable to many actors with data center-level fleets of GPUs”.
The economics matter more than the mathematics. That compute was not procured, it was scavenged from the gaps between other jobs, and the porting was done with an agent. Attack cost is increasingly set by somebody else’s spare capacity.
So we went looking for 1024-bit RSA in Ireland
DKIM is the best place to look, because DKIM public keys are published in DNS on purpose: anyone attacking you can measure them, so you may as well measure them first. The method was deliberately unglamorous: query the TXT record at <selector>._domainkey.<domain>, decode the p= value, parse the RSA modulus and count the bits. Here it is as a one-liner, tested against live records:
dig +short TXT selector1._domainkey.revenue.ie \
| tr -d '"\n ' | sed 's/.*p=//;s/;.*//' \
| base64 -d | openssl rsa -pubin -inform DER -noout -text | head -1
Public-Key: (1024 bit)We ran a control probe first, because an absence only counts if the query would have found a presence: the same selectors returned nothing on a domain we control and on one that does not exist. The 47 weak keys sit across 27 domains, among them state bodies, banks, insurers, utilities, universities, retailers and broadcasters.
RFC 8301, published in January 2018, says signers “MUST use RSA keys of at least 1024 bits” and “SHOULD use RSA keys of at least 2048 bits”. It also tells verifiers they “MUST NOT consider signatures using RSA keys of less than 1024 bits as valid”. Read together: 1024 is the floor, 2048 the expectation, and every receiving mail server is obliged to accept 1024 without complaint. No market mechanism will retire these keys for you.
Nobody chose these key sizes
The weak keys are not randomly distributed. They cluster on two vendor defaults.
Microsoft 365. The selector1 and selector2 records are CNAMEs pointing into onmicrosoft.com, tenant name usually visible in the target. Microsoft’s cmdlet still creates 1024-bit keys unless you pass -KeySize 2048, and its rotation command upgrades only the selector that is not currently signing. Moving a tenant to 2048-bit therefore takes two runs, roughly four days apart, and stopping after the first leaves a 2048-bit key and a 1024-bit key live as a pair. Three domains in our sample stopped exactly there. Three more had both selectors at 1024, three had finished properly: the fingerprint of a two-step job nobody owned to completion.
SendGrid. The s1 and s2 selectors are SendGrid’s automated-security rotation pair, and 21 of our domains publish both. On every one of them s1 was 2048-bit, and on 13 of them s2 was 1024-bit. SendGrid’s documentation explains it: new automated-security keys are 2048-bit, but existing selectors do not change on their own, and reusing a default selector can reuse the 1024-bit key behind it. The remaining weak keys sat on Mandrill and Mailchimp selectors, the same story with a different logo on it.
None of this is a misconfiguration. Every one of these organisations followed the vendor’s instructions correctly. The key size was chosen years ago by a default, and defaults have no owner, no ticket and no review date.
A rotating pair is only as strong as its weaker half
When two selectors form a rotation pair, your effective key strength is the minimum of the two, not the maximum. An attacker does not have to break the key you are proudest of; they break the one that is also published, also valid, and accepted by every verifier because RFC 8301 says it must be. Half an upgrade is not half the benefit. Until both halves are regenerated it is close to none of it.
DKIM is worth caring about in a way a dusty internal certificate is not, because the failure mode is so specific: a forged signature is a phishing email that passes DMARC from your own domain and lands with every authentication indicator green. When we wrote about DMARCbis and the 68% enforcement gap in July, the axis was policy: whether you publish an enforcing record at all. Key strength is the orthogonal axis, and nobody measures it. You can sit at p=reject with perfect alignment and a 1024-bit signing key.
Three caveats we would rather print than have pointed out to us. 1024-bit RSA has never been publicly factored and the distance from 896 bits is large, so nothing about Saturday means your email gets forged on Tuesday. A published selector is not proof a key is actively signing; some are dormant records from vendors long since dropped. And some mixed pairs will be a rotation in flight, finished by the time you read this. None of it changes the shape of the finding: a key size deprecated eight years ago is still in your DNS because a default put it there, and the price of attacking it has just been restated in idle GPU time.
The inventory that is not a certificate inventory
A certificate inventory watches TLS expiry, because expiry causes outages and outages cause phone calls. It is blind to signing keys, because a weak signing key never breaks anything until somebody uses it against you. What is worth half a day is a key inventory, organised by where keys hide and carrying a measured length and a named owner per entry:
- DKIM selectors at every sending service, not just the primary one: marketing, transactional, helpdesk, CRM.
- SAML and OIDC signing certificates at your identity provider and everything trusting it, frequently 1024-bit if the federation predates 2015 and was renewed rather than regenerated.
- JWT signing keys: any
RS256key behind a session or internal API. Check the modulus, not the algorithm name. - Code-signing keys and internal certificate authorities, where the root is the oldest key in the building and the one nobody dares touch.
Then do the governance half: record key size in your DNS-as-code repository so a 1024-bit value turns up in a pull request diff rather than a security review three years later. If you are running a post-quantum programme, this work runs in the opposite direction and is the more urgent of the two. We argued last week that the post-quantum conversation skips the legs of a connection nobody owns; the same blindness is why keys deprecated in 2018 still sign your email in 2026.
REPTILEHAUS runs this as a fixed piece of work: enumerate every signing key across your DNS, identity provider, CI/CD pipeline and infrastructure, measure it rather than trust the vendor documentation, give it an owner, and wire key length into your infrastructure-as-code checks so the next default cannot get in silently. If you would like the sweep run across your own domains, get in touch.
📷 Photo by Georg Bommeli on Unsplash
