Last week, researcher Matthew McPherrin sat down at a Ryzen 9 5950X — a desktop CPU you can buy used for a couple hundred bucks — and factored the private RSA keys of a real, once-trusted Certificate Authority. Not a toy example. A CA that Netscape shipped, by default, to millions of browsers.
It took 32 hours. On a gaming PC. In your living room.
If that doesn't unsettle you, it should. Here's why, and here's what it means for the systems you're running right now.
The target: E-Certify, born in 1999, still technically "trusted" by some ancient client
In March 1999, Netscape 4.51 shipped with two root certificates from a Canadian CA called E-Certify:
- E-Certify RSA 512 Gold Server (for SSL)
- E-Certify RSA 512 Gold Client (for S/MIME)
Both were 512-bit RSA keys. Netscape pulled these roots by 2002, and the certs formally expired October 16, 2003. So on paper, this is ancient history — a dead CA nobody has thought about in twenty years.
Except cryptographic trust doesn't actually die on a schedule. It dies when someone can no longer forge it. And as of last week, someone can.
McPherrin ran CADO-NFS, an open-source number field sieve implementation, against both keys:
- SSL key: factored in 32 hours
- S/MIME key: factored in 29 hours
Total cost: electricity for a consumer desktop over a weekend. That's it. No cluster, no cloud budget, no nation-state resources. For reference, Steve Weis separately factored a 512-bit VeriSign test code-signing CA in about an hour using a GPU cluster.
With the private key in hand, McPherrin didn't stop at "I factored a number." He minted a fraudulent certificate under the resurrected CA, wrote a custom SSLv3 stack (because modern Go's crypto/tls dropped SSLv3, RC4-MD5, and the old 40-bit export ciphers entirely — there's nothing left in the standard library that even speaks this dialect), and stood up a working TLS server at e-certify.fly.dev that a stock Netscape 4.51 install from 1999 will happily connect to and trust today.
That's not a proof of concept. That's a working exploit against a browser people might still be running on some forgotten industrial machine, kiosk, or embedded device.
Why this was always going to happen
512-bit RSA wasn't weak by accident — it was weak by design. During the crypto export-control era of the 1990s, the US government calibrated key-length restrictions so that intelligence agencies could break exported "export-grade" crypto while casual attackers couldn't. E-Certify shipping 512-bit keys in 1999 wasn't even defensible for its time: RSA-155, also 512 bits, was publicly factored later that same year by an academic team with far more modest hardware than what sits under your desk today.
The trajectory since has been brutally linear:
| Key size | Status |
|---|---|
| 512-bit | Factored on a desktop CPU in ~30 hours |
| 862-bit (RSA-260) | Factored recently by researchers with modest clusters |
| 1024-bit | ~2,000 GPU-years — expensive, but "well within the range of anyone with a serious budget" per HN commentary |
| 2048-bit | Hundreds of thousands to millions of years with current techniques |
1024-bit RSA is already deprecated across major PKI ecosystems. 2048-bit has a scheduled deprecation path too, driven by the eventual arrival of practical quantum attacks. None of this is new information. What's new is watching the timeline collapse in real time, on hardware anyone can own.
The part that should actually worry you: batch GCD
Factoring one key at a time is a party trick. The real threat is batch GCD.
If two RSA keys share a prime factor — because a device generated them with a broken or low-entropy RNG — you can recover both private keys almost instantly just by computing gcd(n1, n2) across your entire dataset of public keys. No sieve, no supercomputer, just arithmetic across everything you can scrape.
This isn't theoretical. Researchers factored 184 distinct 1024-bit RSA keys from Taiwan's national Citizen Digital Certificate system — keys generated by government-certified smart cards — and 103 of them were broken purely because they shared primes with each other. "Certified secure" hardware. Real national ID infrastructure. Broken with a GCD computation.
If your fleet of IoT devices, embedded controllers, or smart cards generates RSA keys with anything less than a solid entropy source, you don't need a number field sieve. You need someone to scrape your public keys and run one GCD pass across the lot.
What to actually do about this
Audit what your systems still trust. Pull the trust store from your embedded devices, medical equipment, industrial control systems, and anything running an OS image from before 2010. If a 512-bit or 1024-bit root is still in there, it is not "legacy cruft that doesn't matter" — it is a live attack surface, because factoring it is now a weekend hobby project, not a nation-state capability.
Check your key generation for shared primes. If you provision RSA keys at scale — device fleets, smart cards, embedded certs — run a batch GCD check against your own key corpus before someone else does it for you. It's cheap, it's fast, and it will tell you immediately if your entropy source is broken.
Don't assume "old" means "safe to ignore." The reason this CA mattered in 2026 isn't that anyone is using Netscape 4.51 for online banking. It's that trust relationships don't get automatically revoked just because a protocol falls out of fashion. Whatever accepted that root cert twenty years ago might still be sitting in a warehouse, a factory floor, or a forgotten VM, still willing to shake hands with anything bearing the right signature.
Stop trusting anything under 2048 bits, full stop. Not "when it's convenient." Not "after the next audit cycle." 512-bit died in 1999 and just had its corpse dug up as a demo. 1024-bit is priced at roughly 2,000 GPU-years right now, and GPU-years get cheaper every quarter, not more expensive.
One more thing worth flagging, because it's relevant to literally every engineer reading this in 2026: commenters on the original thread pointed out that parts of the certificate-extraction tooling leaned on an LLM, and the output looked plausible but wasn't fully verified. That's the exact failure mode you'd expect — LLMs are excellent at producing confident, structurally correct nonsense. If you're using one to touch anything security-adjacent — cert parsing, trust-bit classification, key handling — verify the output against ground truth before you ship it. "Looked right" is not a security property.
The lesson here isn't "haha, old crypto is bad." It's that the shelf life of a cryptographic assumption is shorter than the shelf life of the hardware that depends on it. Somewhere right now, there's a device on your network still trusting a root you forgot existed. Go find it before someone else factors it first.
Top comments (0)