⏱️ Lectura: 9 min
A researcher reconstructed, on his own desktop, the 512-bit RSA private key of a real certificate authority: one that Netscape 4.51 marked as trusted for SSL in March 1999. The finding puts no one at risk today, since that root expired in 2003 and was removed from browsers in 2002.
📑 En este artículo
But the experiment puts concrete numbers on the table: how many hours of computation are needed today to break what was considered secure 25 years ago. In this case, the answer fits into a long weekend with a single desktop processor.
TL;DR
- Matthew McPherrin factored two 512-bit RSA keys from the Canadian CA E-Certify, trusted in Netscape 4.51 since March 1999.
- He used CADO-NFS on a Ryzen 9 5950X: 32 hours for the “Gold Server” key (SSL) and 29 hours for “Gold Client” (S/MIME).
- RSA-155, also 512 bits, had already been factored in 1999, the same year Netscape issued these roots.
- Netscape removed the E-Certify roots in 2002; the certificate expired on October 16, 2003.
- Internet Explorer never distributed 512-bit SSL roots, so the experiment is limited to that Netscape window.
- McPherrin published the private keys, certificates, and code on GitHub, at mcpherrinm/ancientroots.
- To verify it, he set up a custom TLS server in Go, published at e-certify.fly.dev, compatible only with Netscape 4.51.
- The roots were found by extracting certificates from archived historical installers, with the help of Claude Code.
What happened
On September 7, 2026, developer Matthew McPherrin published on his personal blog the full story of how he factored the RSA keys of a real certificate authority from the nineties. It all started with a simple question: is there a root certificate weak enough to break with a modern desktop computer?
To answer it, he downloaded the historical Netscape and Internet Explorer installers hosted on the Internet Archive and used Claude Code to automatically extract all the roots included in each version, publishing the result on a filterable web page. Searching by key size, he found his target: in March 1999, Netscape 4.51 distributed two 512-bit root certificates from the defunct Canadian authority E-Certify, one enabled for SSL (“Gold Server”) and another for S/MIME (“Gold Client”).
Internet Explorer, on the other hand, never included 512-bit SSL roots, so the window for this experiment was limited to a very specific stage of Netscape between 1999 and 2002.
The following diagram summarizes the complete process, from extracting the archived roots to loading a page signed with the reconstructed key in the original 1999 browser:
flowchart TD
A["Archived Netscape and IE installers"] --> B["Root extraction with Claude Code"]
B --> C["Filter: 512-bit RSA certificates"]
C --> D["CADO-NFS factors the modulus"]
D --> E["Private key reconstruction"]
E --> F["Issuance of a signed certificate"]
F --> G[("Custom TLS server in Go")]
G --> H["Netscape 4.51 loads the page"]Context and history
RSA’s security depends on factoring a large semiprime being computationally expensive, but how large that key needs to be changes over time. In 1999, the same year Netscape issued the E-Certify roots, an international team had already factored RSA-155, a 512-bit semiprime from the RSA Factoring Challenge. In other words: the key that Netscape marked as trusted for encrypting traffic was already, in theory, insecure from birth.
The bar keeps rising over time. Just a few days ago, someone completed the factorization of RSA-260, an 862-bit semiprime and the largest known public factorization to date. The Web PKI, the trust system browsers use, stopped accepting 1024-bit RSA keys more than a decade ago. Today the minimum standard is 2048 bits, though that size also has an expiration date once quantum computers capable of running Shor’s algorithm eventually arrive.
That historical context matters to understand why a 512-bit root even existed in 1999: Netscape launched SSL support in 1994, in the middle of an era of cryptography export restrictions imposed by the United States, when the industry still had no minimum key size standards for certificate authorities.
Technical details: how the 512-bit RSA was factored
To reconstruct the private key from the public one, McPherrin ran CADO-NFS, an open source implementation of the general number field sieve (GNFS), the classic algorithm for factoring large semiprimes. The process consists of several phases: polynomial selection, sieving, relation filtering, linear algebra, and final square root. For a 512-bit modulus, the sieving phase is the most time-consuming on desktop hardware.
The work ran on a desktop Ryzen 9 5950X, no cluster or GPU: 32 hours to factor the “E-Certify RSA 512 Gold Server” key and 29 hours for “E-Certify RSA 512 Gold Client”. The following table places that result within the historical scale of known RSA factorizations:
| Key | Size | Status | Time or milestone |
|---|---|---|---|
| RSA-155 | 512 bits | Factored in 1999 | International distributed effort |
| E-Certify Gold Server | 512 bits | Factored in 2026 | 32 hours on a Ryzen 9 5950X |
| E-Certify Gold Client | 512 bits | Factored in 2026 | 29 hours on a Ryzen 9 5950X |
| RSA-260 | 862 bits | Recently factored | Largest known public factorization |
| 1024-bit RSA | 1024 bits | Deprecated by the Web PKI | No confirmed public factorization |
| 2048-bit RSA | 2048 bits | Current minimum standard | In use in modern TLS certificates |
A simplified example of how CADO-NFS is invoked on a composite number (a toy semiprime to illustrate the syntax, not the real key):
./cado-nfs.py 2087213345157128459857544877488990849241708931948717
# the tool runs the sieving, filtering, and linear algebra phases,
# and finally prints the two prime factors foundWith the public modulus of the real certificate, the command is the same, but the number is 512 bits long: the difference lies in the computation time, not the algorithm. To confirm that a reconstructed private key truly matches the public certificate, the modulus of both is compared:
openssl x509 -noout -modulus -in e-certify-gold-server.pem | openssl md5
openssl rsa -noout -modulus -in e-certify-gold-server-key.pem | openssl md5
# if the two hashes match, the private key is valid for that certificateHow to test it
McPherrin published the private keys, original certificates, and tools used in the repository github.com/mcpherrinm/ancientroots. Anyone running Netscape 4.51 in a virtual machine with the clock set back to before October 2003 can use them to issue certificates and test them against e-certify.fly.dev, a custom TLS server written in Go that McPherrin had to build because no modern TLS stack shares ciphers with that 1999 browser.
To install CADO-NFS and reproduce the factorization part on your own machine, using a smaller number unless you have several free days of CPU time:
# Linux (Debian/Ubuntu)
sudo apt install build-essential cmake libgmp-dev
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make# macOS (Homebrew)
brew install cmake gmp
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make# Windows (via WSL2; CADO-NFS has no native Windows build)
wsl --install -d Ubuntu
wsl
sudo apt install build-essential cmake libgmp-dev
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && makeImpact and analysis
The result reopens no real risk: the E-Certify root was removed from Netscape in 2002 and the certificate expired in 2003, so no modern traffic depends on that chain of trust. The value of the experiment lies elsewhere: it shows, with concrete hours and hardware, the gap between what was considered secure in 1999 and what the Web PKI requires today.
💭 Key point: the same year Netscape was issuing a 512-bit root, RSA-155, also 512 bits, had already fallen. The weakness wasn’t a hidden technical secret: it was public from day one.
The case also illustrates how the availability of computing tools has changed. In 1999, factoring RSA-155 required an international effort distributed among several research groups over months. In 2026, a desktop with a single Ryzen processor did the same work, for a key of the same size, in under a day and a half.
⚠️ Heads up: replicating tests with old TLS stacks, like the custom server for Netscape 4.51, should always be done in isolated environments, never against production traffic or real users.
For today’s certificate authorities, the underlying message is the same one the CA/Browser Forum enforces today: minimum key size isn’t an aesthetic preference, it’s an expiration date calculated according to the computing power available at each point in time.
What’s next
According to McPherrin himself, the margin for repeating this experiment is narrow: Internet Explorer never distributed 512-bit SSL roots, so the window is limited to that very specific stage of Netscape between 1999 and 2002. The catalog of old roots he generated with Claude Code remains available regardless, so other researchers can keep looking for similar cases in installers from that era.
In parallel, the migration toward post-quantum cryptography is moving forward for the same reason that brought down these 512-bit roots: available computing power only grows. NIST has already standardized ML-KEM (FIPS 203) as a replacement for key exchange schemes based on factoring and discrete logarithms, anticipating the day when a sufficiently large quantum computer does to 2048-bit RSA what a desktop Ryzen already does today to 512-bit keys.
📖 Summary on Telegram: View summary
Try it yourself: clone mcpherrinm/ancientroots and run openssl x509 -noout -modulus on old certificates you have on hand to see what key size your own browsing depended on 25 years ago.
Frequently Asked Questions
Does this finding put current browsing at risk?
No. The E-Certify root was removed from Netscape in 2002 and the certificate expired on October 16, 2003, so no modern browser trusts it.
How long did the factorization take?
32 hours for the “Gold Server” key and 29 hours for “Gold Client”, both 512 bits, running CADO-NFS on a desktop Ryzen 9 5950X.
What is CADO-NFS?
It’s an open source implementation of the general number field sieve (GNFS), the standard algorithm for factoring large semiprimes like RSA moduli.
Why was a 512-bit key already weak in 1999?
Because that same year an international team factored RSA-155, another 512-bit semiprime from the RSA Factoring Challenge, publicly demonstrating that size wasn’t enough.
Can the experiment be reproduced?
Yes. The private keys, original certificates, and tools are published in McPherrin’s GitHub repository, along with the custom TLS server for testing them with Netscape 4.51.
What RSA key size is considered secure today?
The minimum accepted by the Web PKI is 2048 bits, though migration toward post-quantum schemes like ML-KEM is already underway ahead of the risk posed by quantum computers.
References
- mcpherrin.ca: Matthew McPherrin’s original post with the full detail of the factorization process.
- github.com/mcpherrinm/ancientroots: repository with the private keys, certificates, and tools used.
- cado-nfs.gitlabpages.inria.fr: official page of the CADO-NFS project, the factorization tool used.
- en.wikipedia.org/wiki/RSA_Factoring_Challenge: history of the RSA Factoring Challenge, including RSA-155.
- csrc.nist.gov: NIST’s FIPS 203 (ML-KEM) standard for post-quantum cryptography.
📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
0 Comments