I've factored the RSA keys of a Certificate Authority from the 90s

I've written and worked on a few TLS implementations, so it wasn't terribly interesting to me. And I have to go to work tomorrow and solve real, modern CA problems :)

But in short, I wanted to use Go, and it doesn't support SSLv3, the SSLv2 Client Hello, or the 40-bit RC4-MD5 export-grade cipher suites which I wanted to support too.

I was more shocked that I managed to get stock OpenSSL to issue a certificate that worked. There's a number of things that didn't work there, too. You can find my scars in mkcert.sh in the repo. Perhaps all of this is worthy of a follow-up post.

I could have tried to get some old server running instead, but I wouldn't have wanted to deploy that on the internet, even on an isolated Fly VM.

They used a similar kind of custom (and flawed) TLS implementation in their game(s) which allowed signing new certificates after brute forcing.

The benefit to this is that users can now play these games without needing to burn a new CD with either the SSL certs swapped, or the code patched to dummy out the checks. A "retail CD" will simply work with private servers now.

I've also been on the other side of the fence, building a "retro internet" service [1] has meant trying to implement ancient SSL/TLS services for things and people that want to use them on the network.

Getting modern OpenSSL (aka what ships in Debian) to even accept these ciphers, let alone keys that short is an uphill battle. Understandably, they're disabled by default and (in Debian at least) the cipher support isn't even compiled into the binary! This requires building a custom OpenSSL to build Nginx against to serve ancient SSL.

Presumably for the OP this kind of work was either outside of their realm of knowledge, or simply "easier" to outsource to the slop machine. Though I hope the machine they're running their demo TLS implementation on is separated completely from their own network. Rolling your own crypto libraries is always a bad idea [2] and I doubt LLM's have "improved" that

[1] https://www.youtube.com/watch?v=cSJsGNIDjtc

[2] https://soatok.blog/2025/01/31/hell-is-overconfident-develop...

Looks like 70% of cloudflare requests are using post-quantum TLS! https://radar.cloudflare.com/post-quantum

Probably not too many, because anonymous political speech from 10+ years ago isn't that interesting. Punishing people a decade after the fact isn't very effective for anything.

The CADO-NFS page gives some benchmark results for 16 threads, suggesting the algorithm parallelises at least somewhat well.

> How do I verify such claim?

Step 1: Become a cryptography expert. ;)

The security of RSA however depends on the factoring of very large numbers, and that means that for example, RSA-2048 doesn't translate into 2048 bits of security but 112 (roughly symmetric equivalent) bits based on the best factoring algorithms (for comparison, the RSA-512 the article mentions has an 56 bit equivalent and RSA-1024 has a 80 bit equivalent security, so RSA-1024 would take roughly 2^(80-56) ~= 17 million times to compute the worst-case scenario and RSA-2048 would take 2^(112-80) = 4.3 thousand million times more).

According to the Wikipedia article on RSA numbers, RSA-220 (66b) was factored in 2016, RSA-230 (69b) in 2018, RSA-240 (72b) in 2019 and RSA-260 (76b) this year, which is too close to RSA-1024 (80b) to be comfortable.

For RSA-250, the team reported it took "roughly 2,700 core-years, using Intel Xeon Gold 6130 CPUs at 2.1 GHz.". I am not going to (or feel qualified to) make estimates of how that would translate to RSA-1024, but it does sound plausible given enough resources.

A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths https://cr.yp.to/bib/2000/silverman.pdf

It was a response to the idea that 1024 bit RSA was under threat at the time.

The biggest thing I'm afraid of is that the generated scripts missed some entries, or otherwise mis-classified them, in particular whether it got the trust bits right for each root. I would put the chances of that having some errors relatively high.

But there's too many roots across too many browser installers, so I'm not going to confirm the Netscape UI matches what the extracted data says.

When a research team actually factored RSA-155 in August 1999, it took 8,400 MIPS-years due to efficiencies discovered. It still took 35 CPU-years spread across a cluster of 300 fast SGI/SUN workstations and Pentium II PCs (400-500 MIPS each), crunching in parallel for seven months. https://cs.ccsu.edu/~pelletie/local/risks/cryptography/Facto...

Robert Silverman, a senior research scientist at RSA Laboratories, published an analysis projecting these new hardware requirements against Moore's Law. His expectation was that within 10 years (roughly 2009–2010), common desktop machines would possess the speed and memory necessary to handle a 512-bit factorization entirely on their own. https://cr.yp.to/bib/2000/silverman.pdf

PGP (1991) was considered secure as it was considered not brute forceable. With 128 bits, it was considered military grade at the time and the US had an export restriction due to that. That might have been an incentive for GNU Privacy Guard. In France you had to give your private key to the government authority if an encryption system used anymore than 56 bits (as I recall, I don't remember the exact number).

Consumer hardware doing it in a couple of days in 2025 is roughly in line with Moore's Law extrapolations people were drawing at the time. The surprise isn't really the timeline. It's that someone did it as a weekend project rather than a nation-state effort.

Steve Weis, who has been doing RSA factoring on some large GPU clusters, estimates factoring 1024-bit RSA would take about 2000 GPU-years, which is well within the range of anyone with a serious budget.