Two Certificate Authority Keys, One Desktop PC, Sixty-One Hours

In March 1999, Netscape Communicator 4.51 shipped with a list of certificate authorities it trusted. Two of them, both from an outfit called E-Certify, used 512-bit RSA keys.

On 7 September 2026, Matthew McPherrin factored both of them on a desktop computer.

Not a cluster. Not rented cloud. A Ryzen 9 5950X, a chip you could buy for gaming, running CADO-NFS, which is free software anyone can download. The E-Certify Gold Server root, the SSL one, took 32 hours. The Gold Client root, used for S/MIME, took 29 hours.

Sixty-one hours. One desktop. Two certificate authority private keys, recovered from nothing but the public certificates that shipped in a browser twenty-seven years ago.

Separately, Steve Weis factored the Test VeriSign Commercial Software Publisher CA, a code-signing root that shipped in Internet Explorer 3.02, in about an hour using a GPU cluster.

Nothing is on fire

Let us get the responsible part out of the way, because it is load-bearing for why this is fun rather than alarming.

These keys are extravagantly dead. The E-Certify roots were removed by Netscape in 2002 and expired on 16 October 2003. The VeriSign test CA expired on 2 May 1997, which is to say it expired before a meaningful number of people reading this were born, and it was a test CA to begin with.

No browser has trusted any of them for over two decades. Holding these private keys lets you forge certificates that every piece of software on earth will reject. It is a skeleton key to a building that was demolished.

Which is precisely why it is worth looking at closely. Nothing is at stake, so you can see the mechanism clearly.

What actually happened to the security

Here is the thing that makes this a good story rather than a stunt.

Nobody broke RSA. The maths of RSA is exactly as sound today as it was in 1999. No flaw was found. No clever new attack. The algorithm is fine.

What happened is that 512 bits stopped being a lot.

RSA's security rests on factoring being hard: given a large number that is the product of two primes, find the primes. The difficulty scales with size, and in 1999, factoring a 512-bit number was a genuine research achievement requiring coordinated effort across many machines.

Between then and now, two things happened at once, and they multiply rather than add. Computers got dramatically faster. And the algorithms got much better, because the number field sieve and its implementations absorbed twenty-seven years of improvement. CADO-NFS is a mature, tuned, free implementation of techniques that were cutting-edge research when these certificates were issued.

So a thing that was a serious research project in 1999 is now a weekend, unattended, on hardware bought for playing games.

The security did not fail. It expired. Those are different, and the difference is the whole point.

The number that should bother you slightly

512-bit RSA was not a mistake in 1999. It was a defensible choice under the constraints of the day, which included CPUs that made bigger keys genuinely slow.

So the question that follows is uncomfortable and correct: what are we choosing right now that is defensible today and factorable on a hobbyist's machine in 2053?

For classical computing the honest answer is that 2048-bit RSA is not in near-term danger from Moore's law alone, because the difficulty does not scale linearly and 2048 is very far from 512. The margin is real.

But this is where the example earns its keep, because there is a second clock.

This is the post-quantum argument, told concretely. The usual version is abstract and easy to dismiss: a sufficiently large quantum computer running Shor's algorithm would break RSA and elliptic curve cryptography, but no such machine exists, and the timeline is contested. It feels like a problem for someone else's decade.

The E-Certify keys are what that argument looks like when it has already happened. Not a theory about future capability. A capability that arrived, quietly, while the certificates sat in an archive of an old browser. Nobody sent a warning. The keys did not stop working on a particular Tuesday. The cost of breaking them declined continuously until a hobbyist could do it over a weekend, and at no point was there an event.

That is the actual model for cryptographic obsolescence, and the reason "harvest now, decrypt later" is a real concern rather than a slogan. Traffic captured today, stored, and decrypted when the cost falls far enough is the same story with a different algorithm.

Three things to take from it

Cryptographic choices have expiry dates, and the expiry is not announced. Anything you deploy has a window during which it is sound, and that window is set by hardware and algorithmic progress you do not control and cannot observe directly.

Ask how long your data has to stay secret. This is the question that decides whether any of this matters to you. A session token needs to resist attack for minutes. A TLS session needs hours. But medical records, legal documents, source code, and anything covered by a long retention obligation need to resist attack for decades, and that is the category where the second clock matters, because the attacker gets to choose when to try again with better tools.

Crypto agility is the actual requirement. Not picking the right algorithm; you cannot, because the right answer changes. The requirement is being able to change algorithm without rewriting the system. If your protocol hardcodes a cipher, your replacement cost is a migration. If it negotiates, your replacement cost is a config change. That difference is what determines whether the next transition is manageable.

The last thing

There is something genuinely charming about the shape of this. A piece of 1999 software, sitting in an archive, containing the public half of two keys nobody has thought about since the Bush administration. A person with a desktop PC, some free software, and a weekend. And out the other end, two private keys that once secured a commercial certificate authority.

No vulnerability. No exploit. No cleverness beyond patience and a decent CPU.

Just time, doing the thing time does to cryptography.

Source. Factoring RSA keys from old certificate authorities, Matthew McPherrin, 7 September 2026, for the keys, hardware, timings and dates above, including Steve Weis's GPU-cluster result on the VeriSign test CA. Related here: attestation proves a hash and what is a sandbox escape.