I’ve factored the RSA keys of a Certificate Authority… | Matthew McPherrin Home | About Matthew McPherrin 2026-09-07 I’ve factored the RSA keys of a Certificate Authority... … from the 90s. I’ve been thinking about the security of RSA lately. RSA’s cryptography relies on the difficulty of factoring a large semiprime number, but what “large” means is an interesting question. The Web PKI deprecated 1024-bit RSA over a decade ago, and while I don’t know of anyone factoring a key of that size, it’s within the realm of possibility for a government or other organization with a large number of computers. Just a few days ago, someone factored the 862-bit RSA-260 key from the RSA factoring challenge. That’s the largest factorization I’m aware of. Today, the world uses RSA of at least 2048 bits, but even that will be deprecated soon with the risk of quantum computers in the future. This led me to wonder: small RSA keys can be factored on even a modest desktop computer. And in the early days of the Web PKI, there were no standards, and no minimum requirements. Netscape shipped SSL support in 1994, and IE shortly afterwards. This was still the era of export restrictions on cryptography. Are there any keys small enough that I can factor? I don’t have any good reason to do that, but it seems like fun. The spoiler is of course, yes, but first we need to find a key to crack. Fortunately, root certificates were shipped with browser installers, and there are archives of both Internet Explorer and Netscape on archive.org. The archives aren’t comprehensive, but they should provide good coverage of old root CAs. I downloaded both collections and set Claude Code on extracting all the roots. I’ve hosted a Claude-generated webpage with all those old-timey, ancient roots . While I haven’t verified this LLM output is entirely trustworthy, it looks pretty plausible. Using the filters on that site, we can find what small keys are trusted for SSL. Aha! We have a target. Back in March 1999, Netscape 4.51 shipped a 512-bit RSA certificate authority trusted for SSL, and another for S/MIME. These two roots were both from the long-defunct Canadian certificate authority called E-Certify . Later that year, the 512-bit RSA-155 was factored, so even in its era this was too weak and probably shouldn’t have shipped in the first place. The E-Certify 512-bit roots were removed by Netscape in 2002. Unfortunately, Internet Explorer seems to have never shipped any 512-bit roots for SSL, so our fun will be limited to Netscape from a relatively small time frame. Factoring the public keys in the root certificates will give me the two primes that I need to reconstruct the private key. I ran CADO-NFS on my Ryzen 9 5950X desktop; it took 32 hours to factor E-Certify RSA 512 Gold Server for SSL, and another 29 hours for E-Certify RSA 512 Gold Client for S/MIME. You can get the resulting private keys below. Assuming you’re somehow running Netscape 4.51 with a clock set before E-Certify roots expired on 2003-10-16, you can use these private keys to issue certificates. This describes zero people on the planet… except for this VM I set up. Verifying that the issued certificates would work in Netscape 4.51 was an adventure in itself, as there is zero overlap in TLS capability between Netscape 4.51 and any modern TLS stack. So it was back to Claude Code to make a custom old-timey TLS server in Go. This site is publicly hosted at e-certify.fly.dev , which you are welcome to try out with your ow
I was the product manager with responsibility for root certificates in the Netscape 4.51 browser. It's crazy to see someone factor it 25 years later.
Just to reply to some people in the comments. Yes, we knew export grade encryption was weak - that was the point - that the NSA could decrypt it - and the govt. required us to do it anyway.
FWIW - we had the goal of expanding the list of root authorities in the 4.5x release - and this might have been the first release to monetize the root slots because Netscape was under severe pressure to generate revenue.
(Also - Verisign hated that we were expanding competition and tried to convince us to implement a program that would re-restrict the list to a set of "responsible" companies aka Verisign and one or two others. We declined.)
A bit unfortunate that so many of the interesting bits were left to ai. I would've enjoyed some commentary on why the custom TLS implementation was necessary. Oh well.
Update: found this explanation in a comment at the top of the (surprisingly short) Go file in the linked repo:
The target client is Netscape Communicator 4.51 (both the 40-bit export build and the 128-bit US build) with its clock set to the year 2000.
Go's crypto/tls cannot help: it dropped SSLv3 in Go 1.14, never accepted the SSLv2-compatible ClientHello that Netscape 4 sends, and never had RC4-MD5 or the 40-bit export suites. So this file carries its own tiny SSLv3 server-side implementation on top of stdlib primitives (RSA PKCS#1 v1.5, RC4, DES, 3DES, MD5, SHA-1). The server key is 512-bit RSA so that export clients can encrypt the premaster secret to it directly, without a ServerKeyExchange.
Basically 2 days on a consumer GPU to crack a 512 bit cert. The thing is much of the traffic back then did not use ephemeral keys. Most of it wasn't even encrypted at all! But about a decade later, it became normal to encrypt everything. I do wonder which governments around the world are just waiting to crack anonymous political speech by recording and saving for later when decryption can happen.
I owned the "broker FTP" service at a hedge fund.
There was a project in 2021 to talk to the banks and brokers that we connected and ask them to upgrade their keys and ciphers to modern versions.
IIRC, the oldest key/cipher was from the late 2000s so it wouldn't surprise me if someone is using RSA keys from the 90s somewhere.
You can read more about how hedge funds use FTP here: https://x.com/alexpotato/status/1809579426687983657?s=20
Or listen to patio11 and I talk about these systems in general here: https://www.complexsystemspodcast.com/episodes/two-banks-can...
I am not a cryptography expert but I am interested in the field. Having said that: I am lately having an hard time understanding the actual strength of a crypto suite based on the underlying problem, the sized of the material and the computation strength needed to break it either via optimization and parallelism capabilities.
The Web PKI deprecated 1024-bit RSA over a decade ago, and while I don’t know of anyone factoring a key of that size, it’s within the realm of possibility for a government or other organization with a large number of computers.
Is it? How do I verify such claim?
Just a few days ago, someone factored the 862-bit RSA-260 key from the RSA factoring challenge.
Yeah, but how much time it required? and what about the resources? It is just a number, it is not all the 861 bits n numbers.
That SSL report with four different automatic 'F's is an amazing punchline
I don’t have any good reason to do that, but it seems like fun.
What better reason is there to do something than it being fun?
While I haven’t verified this LLM output is entirely trustworthy, it looks pretty plausible.
It's essential that you do, because generating pretty plausible outputs is an LLM's bread and butter. Otherwise, only the one that you actually tested should be expected to be correct.
This is amazing news for people building hyper-compatible websites!
Great writeup. The fact that CADO-NFS still takes 32 hours on a 5950X for a 512-bit key that's trivial by today's academic standards really puts into perspective how comically undersized these were even for 1999 — RSA-155 fell that same year. Also love that verifying against real Netscape 4.51 ended up being harder than the factoring itself.