DK Dark Knight 2026-09-04 6 min read

RSA-260 Factored: The 862-Bit Crack

On September 3, an engineer at the AI startup Cognition posted a 130-digit string with the caption "divides RSA-260." That's the largest RSA challenge number ever cracked — 862 bits, nearly six years after the previous record. RSA-260 wasn't supposed to fall to a single person with an unexplained method. I verified the factor myself, benchmarked what real factoring costs, and the claim holds up as math — while the story around it doesn't.

The 130-Digit Factor: Verified

RSA numbers are semiprimes — products of two secret primes — published by RSA Security in 1991 as a factoring challenge. RSA-260 is the 260-decimal-digit one (862 bits). Wikipedia now lists the full factorization, so verification is trivial: multiply the two factors back together. I did exactly that in Python:

# N = p × q, all 260 digits
# N (RSA-260) = 22112825529529666435281085255...58199
p = 4397328654844826923795068102505872571721883526553349659561256924505973939\
    597593482272505698004801207988043088656411102133523080581
q = 5028695206842569864686141618253083416610081090075366674776775706538324961\
    364412200138116378509733307971876652984898985905923678379

print(N == p*q)   # True
print(N.bit_length())  # 862
print(p.bit_length(), q.bit_length())  # 431 431

It checks out. Both factors are 431-bit primes (130 digits each — matching the claimed string), balanced, and the product is exactly RSA-260. The factorization is real, and importantly, anyone can verify it in seconds. That part of cryptography never breaks: checking a factor is trivial even when finding one is a miracle.

Why "Seven Months by Hand" Doesn't Add Up

Here's the problem. The last RSA challenge number, RSA-250 (829 bits), took a 2700 core-year number-field-sieve campaign by an international team in 2020. Emmanuele Thomé of INRIA, who led that effort, estimates RSA-260 at roughly 3x the cost — call it 8,000 core-years. So how does one engineer crack it in seven months?

The reported story: Lu sampled and tested primes "by hand" (with computers, no AI), allegedly finding one that divides RSA-260 through brute-force trial division. I tested how plausible that is. First, the arithmetic it implies: if the factor was uniform random, you'd expect on the order of p/2 ≈ 10¹²⁹ random trials before hitting it. That number has 130 digits. Even at a billion divisions per second it's a googol-scale eternity.

Second, I probed for the classic "lucky" path — a weak key where one factor minus one (or plus one) is smooth, which makes the Pollard p−1 / Williams p+1 methods trivial. That's how real "by hand" factoring wins happen. I sieved both p and q in both directions for all small prime factors up to 10⁶:

# p-1: 423/431 bits remain after removing small factors (only 2^2·5·11)
# p+1: 417/431 bits remain (2·3·13·181)
# q-1: 422/431 bits remain (2·19·23)
# q+1: 414/431 bits remain (2^2·3·5·7·499)

Neither factor has a smoothness weakness. Both are cryptographically clean primes, about 10⁶ bits short — which is exactly what a random prime looks like. There is no shortcut here that a "paper and pencil" search would find. To make sure I wasn't hand-waving about how hard this class of attack is, I ran it:

# Pollard's rho + Miller-Rabin, pure Python, on random semiprimes
#  32-bit semiprime: 0.000s    (10 digits)
#  48-bit semiprime: 0.005s    (15 digits)
#  64-bit semiprime: 0.017s    (19 digits)
#  80-bit semiprime: 0.514s    (24 digits)
#  96-bit semiprime: 4.158s    (29 digits)
# 112-bit semiprime: 134.98s   (34 digits)  <-- 3x digits since 96-bit, 8000x time
# RSA-100 (330-bit): timeouts / doesn't finish — rho is done at ~110 bits

That's the sobering curve: 32 bits to 112 bits is a 4x bit increase and a ~10⁶x time increase. The gap from 112 bits to 862 bits is not a factor — it's a chasm. No amount of "sampling primes while bored" crosses it. So either Lu has a genuinely new factoring idea (which would be the real story, and he hasn't published it), a very large hidden compute budget, or the "no AI" framing is doing a lot of work. Devin, Cognition's agent, was reportedly involved in conflicting accounts. The method claim is the story, and it's still a hole in the ground.

What This Means for RSA Security

Nothing breaks today. RSA in production runs 2048 or 3072 bits; RSA-1024 — the next RSA challenge number up — is estimated at millions of NFS core-years, and RSA-2048 is in "unalgorithmically impossible" territory. But this is a psychological-milestone event, the kind crypto warns about: the record moved from 829 bits (RSA-250, 2020) to 862 bits (RSA-260, 2026) in a way that smells nothing like the last one — this time it might not have been the sieving that did it.

The real takeaway is for legacy stacks. There are still real systems signing with 1024-bit RSA — embedded firmware, old DNSSEC signers, payment terminals from 2015. RSA-250 already demonstrated those are borderline; RSA-260 shrink-wraps the lesson. If the method behind this turns out to be a better-than-NFS technique rather than a one-off stroke of luck, everything at or below 1024 bits becomes urgent. Watch the follow-up papers, not the tweet.

Bottom Line

RSA-260 is factored, the math is verified, and the record advance from RSA-250 is real — but the "one engineer, seven months, no AI" narrative is numerically implausible unless there's an undisclosed method or machine underneath it. The number is dead; the story is alive. If a new factoring technique was used, cryptography is about to have its moment. If it was compute, we just learned what an 8,000-core-year problem looks like when someone actually wants it solved. Either way: check your legacy RSA key sizes this week, not next.

Related