Stephen Weis Factored RSA-896 With Claude on 19 September 2026 in 30 GPU-Years of Idle Capacity: His Claim That 1,024-Bit RSA Is Vulnerable to Data-Center GPU Fleets, Read Against NIST SP 800-131A
In August 1999 a team led by Herman te Riele at CWI in Amsterdam factored RSA-155, a 512-bit modulus, after about seven months of work, most of it sieving on some three hundred workstations, and published the account the following spring. Every competent engineer read it as the end of 512-bit RSA. Sixteen years later, in March 2015, the researchers behind the FREAK attack found that a large share of browser-trusted web servers were still willing to negotiate 512-bit "export-grade" RSA, because the keys had never been removed from the software that offered them. The factorization was the easy part. The key that hurts is the one nobody took out of service.
That is the frame for reading the short note that Stephen A. Weis posted in September 2026. He reports that RSA-896, the 270-digit number from the old RSA Factoring Challenge, was factored "with Claude" on 19 September 2026. The details he gives are few and worth quoting exactly. Claude was used to port CADO-NFS, the open-source implementation of the general number field sieve maintained at Inria, to run on GPUs. It "orchestrated running on a fleet of up to 2048 GPUs as a low-priority job during unused idle time between regular jobs." The computation ran over a ten-day period and consumed about 30 GPU-years of compute at Anthropic. The note's two evaluative sentences are the ones that matter for anyone who holds keys: 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"; and it "demonstrates that RSA-1024 keys are vulnerable to many actors with data center-level fleets of GPUs." More details, he says, will follow.
Practical takeaway. The mathematics did not move. What moved is the engineering labor: an AI coding agent produced a GPU port of a research sieve and scheduled it on spare capacity, so the specialist bottleneck that kept factoring records in a handful of academic groups is lower than it was. For federal systems, NIST SP 800-131A has disallowed 1,024-bit RSA for signing and key transport since 2014 and tolerates it only for verifying old signatures; RFC 8301 still lets a DKIM signer use a 1,024-bit key today. The action Weis's sentence implies is to find every 1,024-bit RSA key that still signs or protects anything, and that is an inventory task the post-quantum migration already requires.
What the 19 September 2026 note says, and what it does not: 30 GPU-years, 2,048 idle GPUs, no price
Three things in the note are precise. The fleet size, up to 2,048 GPUs, is a peak, and the job was explicitly low-priority, filling idle time between regular workloads. The duration, about ten days wall-clock, is the elapsed window in which that idle time was harvested. The work, about 30 GPU-years, is the sum. Two things are absent. There is no dollar figure, and there is no statement of which GPU model was used, so the GPU-year cannot be converted into money without borrowing a rate from elsewhere. The nearest published rate is Cognition's account of RSA-260, which put that factorization at about 4,900 GPU-days, or 13.5 GPU-years, and about $400,000 "at current market prices." Thirty GPU-years is a little over twice that count; at Cognition's rate it would be roughly $900,000 of rented time. Weis's run was not rented time, and he publishes no cost calculation, so what an idle-capacity job actually costs its owner is unstated. The more useful number in Cognition's account is its forward estimate: RSA-1024, about 78 times the computation of RSA-260 on standard GNFS scaling, would cost "roughly $30M" at market GPU prices, and "hyperscalers or frontier AI labs could likely factor RSA-1024 numbers at a cost on the order of $30 million per number." That estimate, not the RSA-896 rental arithmetic, is the figure Weis's sentence should be read against.
The other absence is the algorithmic one, and Weis states it rather than leaving it to inference: no meaningful improvement to the runtime of the general number field sieve. CADO-NFS on CPUs factored RSA-250 in February 2020; a GPU port of the same algorithm factored a number 67 bits longer in September 2026. The record moved because the sieve was made to run on hardware that a large AI laboratory has in quantity and leaves idle in the gaps, and because an agent wrote the port. It did not move because anyone found a faster way to factor.
Where 896 bits sits: RSA-250 at 829 bits in 2020, RSA-260 at 862 bits on 3 September 2026, RSA-896 sixteen days later
The RSA challenge numbers are named two ways, which makes the sequence look larger than it is. RSA-250 and RSA-260 are named by decimal digits: 829 and 862 bits respectively. RSA-896 is named by bits, and is 270 digits. So the record went from 829 bits (February 2020, CADO-NFS on CPUs, an academic team) to 862 bits (3 September 2026, Cognition's Devin, GPUs) to 896 bits (19 September 2026, Claude, GPUs): 33 bits in six and a half years, then 34 bits in sixteen days. Quentir read the first of this month's two results in its 13 September post on RSA-260, and Quentir's conclusion there, that NIST's 2030 and 2035 dates for RSA-2048 do not move, holds for RSA-896 as well in Quentir's reading; Weis's note itself says only that the result "does not impact the security of deployed RSA-2048 keys," and says nothing about migration dates.
The remaining distance to 1,024 bits is 128 bits, and the number field sieve's cost grows sub-exponentially with the size of the number, so each additional bit is more expensive than the last. No properly generated 1,024-bit RSA modulus, such as the RSA-1024 challenge number, has been publicly factored, and Weis does not claim to have done so. What he claims is narrower: that 1,024-bit keys are vulnerable to "many actors with data center-level fleets of GPUs." Cognition's $30 million figure is the published GPU-cost estimate for that claim, and it names the same class of actor. That is the sentence to read against the rules.
The claim under test: are 1,024-bit RSA keys "vulnerable to many actors"? What NIST SP 800-131A Rev. 2 decided for federal systems in 2014
The federal rule was set twelve years before the note, on a strength estimate rather than a demonstration. NIST SP 800-131A, first issued in January 2011 and now in its Revision 2 of March 2019, sets the security-strength floor for federal cryptographic protection at 112 bits, and records that "prior to 2014, a security strength of at least 80 bits" was permitted. A 1,024-bit RSA modulus provides about 80 bits. Table 2 of the revision therefore lists RSA with a modulus under 2,048 bits as disallowed for digital signature generation, and Table 5 lists it as disallowed for RSA key agreement and key transport. The only status a 1,024-bit key retains is "legacy use" for signature verification, meaning an old signature made with such a key may still be checked; below that historic lower bound, for RSA keys shorter than 1,024 bits, verification "shall be regarded as having unacceptable risks." These are guidelines for federal agencies and the systems they procure; they do not bind a private mail administrator, and a standard such as RFC 8301 that sets a different floor is not in legal conflict with them.
So NIST did not establish in 2014 that 1,024-bit RSA could be factored at any particular cost; it judged 80 bits of estimated strength inadequate for federal protection and moved the floor. The September results and Cognition's $30 million estimate supply what the 2014 judgment did not have, a demonstrated 896-bit factorization and a priced extrapolation to 1,024 bits. What is new is the population of actors the estimate names: hyperscalers and frontier AI laboratories, which own the fleets and, on this month's two accounts, the agents that write the ports. Quentir's earlier Defense Monitor piece on what AI cryptanalysis does to post-quantum assurance made a related point about lattice schemes: the assurance question is who can afford the attack, and that population is now larger and less specialized than the standards assumed.
Where 1,024-bit RSA still lives by rule: the DKIM floor in RFC 8301, and the DNS TXT record behind it
If federal rules disallowed the key size in 2014, where would an inventory find one? The clearest documented answer is email. RFC 8301, published in January 2018 to update DKIM's cryptographic requirements, says that "Signers MUST use RSA keys of at least 1024 bits for all keys" and only that they "SHOULD use RSA keys of at least 2048 bits." Verifiers must be able to validate signatures made with keys from 1,024 to 4,096 bits, and may apply their own policy on key length. The RFC explains the floor: some DNS provisioning software "only handles a single 256-octet string in a TXT record, and RSA keys significantly longer than 1024 bits don't fit in 256 octets." A domain whose DKIM selector still carries a 1,024-bit key is compliant with the standard today. An actor who factors that key can produce a DKIM signature that validates for that domain. Under DMARC, that signature passes only if the signing domain aligns with the domain in the visible From header, so a factored key for the domain that actually sends the mail is what an attacker needs; a valid signature alone guarantees neither a DMARC pass nor delivery, but it removes the check that DMARC leans on.
That is the humane end of a factoring record. A hospital's appointment reminders, a bank's fraud alerts, a school district's payroll notices are trusted by receiving mail systems because a signature checks out against a public key in DNS. The web moved off short keys by rule when the CA/Browser Forum's Baseline Requirements set 2,048 bits as the minimum for publicly trusted certificates; email signing kept a lower floor for a tooling reason, and the floor is still in force. The same pattern will exist in code-signing keys on long-lived devices, in SSH keys generated when 1,024 bits was the default, and in hardware tokens issued before 2014. None of those populations is knowable from the outside. They are knowable from an inventory, which is why the OMB memorandum M-23-02 of November 2022 told federal agencies to inventory their cryptographic systems in the first place, as a post-quantum measure; Weis's note gives the same inventory a classical deadline.
How Quentir Reads It
The note should be read as a demonstration about labor, not about mathematics. Factoring records used to require a small community of number theorists and systems programmers who understood the sieve, the linear algebra and the cluster. Cognition's write-up describes about three weeks from first prompt to factors, with an engineer who had factored numbers as a hobby for a decade guiding the agent; Weis's note describes an agent doing the port and the scheduling, with the human effort unstated. The barrier that protected 1,024-bit keys in practice was never only the 80-bit strength estimate, which NIST had judged inadequate for federal use; it was also that few organizations could field the expertise to run a sieve of that size. That barrier is lower after September 2026, and the second result was run on idle capacity whose cost to its owner Weis does not state.
Two things follow. First, the affected population is defined by rules that still permit the key size, and RFC 8301 is the leading example: the standard for email authentication tolerates a key length that NIST disallowed for signing a decade ago, for a reason that has nothing to do with cryptography. A reader who administers a domain can check the selector today. Second, the classical and post-quantum inventories are the same inventory. The systems that still sign with 1,024-bit RSA are the systems least likely to have a migration owner, and finding them is the discovery phase that any post-quantum roadmap begins with. Quentir's Signature Report, the PQC Migration Roadmap, carries that discovery phase as a fixed-scope sequence with an executive summary, refresh triggers as records like this one land, and an internal-use license; this post carries the reading of one note and the two rules it collides with.
Weis promises more details, and the ones worth waiting for are the GPU model, the sieving parameters and whether the linear algebra stage ran on the same fleet, because those numbers determine how far the idle-capacity method reaches. Until then two questions stay open: the practical cost of factoring a 1,024-bit key, for which Cognition's $30 million is the published GPU-cost estimate, and which domains, devices and signing services will still depend on one when someone with a spare fleet decides to find out.
Sources: Stephen A. Weis, "RSA-896" (saweis.net, September 2026; factorization dated 19 September 2026), for the fleet size, ten-day window, 30 GPU-years, the CADO-NFS GPU port, the statement on GNFS runtime and RSA-2048, and the sentence on RSA-1024; Cognition, "Factoring RSA-260" (September 2026), for the 4,900 GPU-day, 13.5 GPU-year and $400,000 figures, the "about three weeks" statement, and the roughly $30 million RSA-1024 estimate; CADO-NFS (Inria), for the software; NIST, SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019; PDF), Section 1.2.2, Table 2, Section 3 and Table 5, for the 112-bit floor, the pre-2014 80-bit allowance, and the disallowed and legacy-use statuses of RSA moduli under 2,048 bits; IETF, RFC 8301, Cryptographic Algorithm and Key Usage Update to DKIM (January 2018), Sections 1 and 3.2, for the 1,024-bit signer floor, the 2,048-bit recommendation and the 256-octet TXT-record explanation; IETF, RFC 7489, DMARC (March 2015), Section 3.1, for identifier alignment; Office of Management and Budget, Memorandum M-23-02 (18 November 2022), for the federal cryptographic inventory requirement; CA/Browser Forum, Baseline Requirements for TLS Server Certificates, for the 2,048-bit RSA minimum; Cavallar et al., "Factorization of a 512-Bit RSA Modulus" (Eurocrypt 2000), and the FREAK attack disclosure (March 2015), cited for the 1999 and 2015 history. Public sources checked 21 September 2026.
Published intelligence, built to inform your own decisions. Published: September 21, 2026.