I don't know how fast my CPU cores are in MIPS, but it's 4.5 Ghz and some random googling indicates that might be about 10 MIPS per Mhz, so 45,000 Dhrystone MIPS.
And assuming about ((32x32 core-hours) / 8766 (hours/year)) x 45,000 = 5256 MIPS-years.
So within the order of magnitude of the 1999 factoring! Of course, the MIPS number is kinda made up, so
That's a good point. I've added to the post. It's simple enough I'd expect anyone who wants to do it can follow the docs from CADO-NFS, which are very good, but I can write it down explicitly.
Install CADO-NFS per upstream directions.
Get the number you want to factor. I just did this in a python repl, something like:
from cryptography import x509
f = open("gold-server.pem", "rb").read()
print(x509.load_pem_x509_certificate(f).public_key().public_numbers().n)
That gets you the `n` to factor - The big number below.
Then pass it to CADO-NFS. The full invocation for the server root was:
Fascinating! My involvement in this space starts much later, so it’s always interesting to hear from folks involved at the time. The rumours about monetizing the root program is one I’ve heard repeated but never anything concrete.
These days with the CA/Browser forum, CCADB, and openly run root programs from Mozilla, Chrome and others, this is all much better documented than what went on in the early days, so I definitely have some strong historical interest in what came before.
At the time there were two root programs, Microsoft's and Netscape's. To get into them, for Microsoft you had to go through a painful third-party audit process, SAS 70 from memory, for Netscape you turned up in Mountain View with a suitcase full of cash (this was the informal description of the process). It cost about the same for both programs, again from memory $0.5M each.
I didn't use any GPUs, but Steve Weis (who factored the final key at the bottom of the post) did. He's posted about that factoring setup over on https://x.com/sweis/status/2095570645505700165
I agree to some degree, but it's not essential for what I wanted to do (which is find a 512-bit RSA key).
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.
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.
I bet all the certificate metadata shown in the „View a certificate“ popup window is vulnerable to cross-site scripting. Back then you probably wouldn’t get a <script> tag through a CA's review process and I found such a problem in Netscape's image „About page“ popup.
If it were vulnerable to XSS, why would you even want it properly signed by a CA?
People almost never inspect the certificates of working websites, the only time they might look at it is when it fails validation.
I actually do like to view certificates of working sites, because it can be interesting to see what's listed in the Subject Alternative Names field. It can lead to some interesting observations about what sites are linked.
Strange seeing how people have such a hard time seeing others using AI and seem to want to complain about it instead of just, well, asking AI why something was likely done a way. It works both ways my dudes, experts don’t need to explain every last detail, prompt a bot with the context until you understand.
From my prospective, the outputs of a bot aren’t the interesting bits, it’s the input prompt that should warrant more attention.
It’s not quite a doubling per bit, which is why RSA keys are relatively large compared to similar-strength ECDSA keys, for example.
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.
Yeah, 2000 years sounds like a lot till you do the math. Apparently astra was trained on 100k Blackwell gpu’s. So just over 7 days to crack 1028-bit rsa on that cluster…
It's hard to extrapolate that far, but maybe hundreds of thousands or millions of years.
Naively looking at scaling factors is going to be tricky, because computation of this scale is going to involve things like "how do I hijack every GPU on the planet", or worrying about when the sun will run out of hydrogen if you're using a single CPU.
says approximately the same as a 112-bit symmetric key, so 1/65536 as fast as however your target platform does at AES128, but probably 2000 times slower again because RSA is a really slow algorithm.
128-bit security is the de-facto minimum standard. Anything less than that is suspect. That's a 3072-bit RSA key. We only ever tolerated shorter keys because RSA is so slow. You should switch to ed25519 if you can.
We don't have any way to predict when and if 2048 bit RSA would be factorable at this time. We would need a breakthrough in hardware and/or algorithms. The common estimation that it is equivalent to the difficulty of brute forcing symmetrical 112 bit encryption seems to be based on some sort of straightforward extrapolation. It doesn't take into account the amount of memory required for the poorly reducible matrix reduction step in the currently known best algorithm. That's 10^18 bytes of memory, or a million terabytes, somehow coupled to enough processing power to actually make anything possible.
Even if you accept the 112 bit estimate, that works out to something like 400 thousand years using the Bitcoin network as a reference to what we could reasonably achieve.
Which isn't a very good margin in cryptography, where we usually aim for things like "longer than the universe's lifetime if every atom was a CPU". But RSA is really slow so we have to compromise encryption speed with cracking speed.
If you make an RSA key so big it'll take the lifetime of the universe to crack if you turn all matter into cracking machines, it'll also take a day to encrypt anything. This is not true about other algorithms.
2048-bit RSA gives something like 28 more bits of security than 1024-bit RSA has, so it would take about 250 million times as long to factor one 2048-bit key.
The linked actual research article did look at multiple GNSS systems. GPS is presumably being reported out of familiarity https://doi.org/10.1029/2026GL124645
This shouldn’t be too much of a surprise, as TLS 1.3 has been out for many years and is widely adopted.
I haven’t paid too much attention to the TLS WG lately (for obvious reasons if you look at their mailing list), but I assume this is mostly a “if you want Post-Quantum cryptography, you need 1.3”.
While I didn't work on AWS, I did intern on the retail side of Amazon, and there's definitely this sort of monitoring in place. Surely somebody was paged. And even if not, this is "just" the cost explorer estimations, not what is ending up on folk's bills.
I've been told a tale of another incident where some customer ran some huge cpu-intensive workload that didn't do any networking. It caused various alarms to fire because it "looked like" a part of the network was idle (potentially indicating some sort of networking failure)
It's generally (in the broad sense) easy to add alarms for things going wrong, but in my experience anomaly detectors are just as likely to fire from other weird things like that happening.
> there's definitely this sort of monitoring in place. Surely somebody was paged.
Well you’re half right. Either there wasn’t monitoring for this or if there was monitoring in place that’s not what caught this, because the page originated from a customer support ticket.
And assuming about ((32x32 core-hours) / 8766 (hours/year)) x 45,000 = 5256 MIPS-years.
So within the order of magnitude of the 1999 factoring! Of course, the MIPS number is kinda made up, so
reply