Rendered at 02:02:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
hnmullany 13 hours ago [-]
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.)
jetbalsa 13 hours ago [-]
Its a shame that Microsoft ate Netscape's lunch so early on. I still use Firefox and have fond memories of Netscape (v7) when growing up.
necovek 7 hours ago [-]
IIRC, Netscape 4.* series was the last in the proprietary line of Netscape Navigators (though 4.* had a broader name like "Communicator" or something, since it included more than just the browser — but "3.0 Gold" was the one I remember most fondly as my first true good browser).
After that, open source efforts to rebuild the entire browser and mail client took years as XUL and Gecko were being built as very generic reusable components, opening up the space for competition to spring up. On top of that, Microsoft leveraged the Windows moat, including IE 3.0 and later 4.0 as the basis of Windows "97" (95 something-something) and 98, along with ActiveX push. By the time legal systems caught up with the practice of bundling a browser into a dominant OS, Netscape and Mozilla were toast.
Everything from there on was an uphill battle, and when KHTML was turned into WebKit by Apple, and adopted by Google for Chrome, there was also an open source engine (or two) supported by infinite money.
That's at least how I remember it, but you are welcome to fact-check me on any of those since this is now 20-30 years ago.
cyanydeez 12 hours ago [-]
Its a shame public internet is npt viewed as a public utility
AnthonyMouse 10 hours ago [-]
How do you imagine that would work for something like this?
Suppose you live in South America, register a domain from a registry in Canada and then have users accessing it from Ukraine. Are we going to give every local government a global root certificate? Have a single one in California or Texas that every other country is somehow forced to use? Or make it so people in Europe can't access sites in Asia and vice versa?
The existing system is more than the usual amount of messed up but that seems like one of the things that could actually make it worse.
otabdeveloper4 8 hours ago [-]
You don't need a "root certificate".
Just publish a public key in your DNS TXT records. ACME is just that anyways but with extra (pointless) steps.
The whole SSL certificate grift is just a way to extort money out of nothing.
mdemare 8 hours ago [-]
Ok, but now you need to trust DNSSEC.
necovek 7 hours ago [-]
The point GP was making is that DNS-record based ACME mechanism for verification of ownership implies trust in the domain name owner (or really, anyone who can edit records in the domain zone), making the issuance of a certificate actually superfluous.
DNSSEC is probably not even used, though I never checked.
Eg. as a domain owner, you will put a cryptographic hash into your DNS zone so a CA can validate you have control over it, and then issue a different cryptographic hash derived from their private key, and browser will use their public key to validate this cryptographic hash (TLS cert) is valid.
So we could simply push public key into a DNS zone, and browsers could use it to decrypt the traffic encrypted by the private key from the server hosted under that DNS name: no CAs needed, similar to SSH except the DNS-ownership-implied-trust component.
"Extended validation" certificates involved a lot more (in theory, checking true ownership, business address, physical presence, etc), but nobody really cares about these, and with the push to automated renewal and 45-day expiration dates by 2028, it's going to make even less sense.
Edit: I realize now that you may be referring to the fact that MITM DNS server can inject a different public key in there and thus DNSSEC is required — you are absolutely right, and this is a good and important point.
cyanydeez 9 hours ago [-]
same way every public utility works. It's great until a capitalist buys your government and forces you to sell it back to them while they rent seek.
mcpherrinm 11 hours ago [-]
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.
CGMthrowaway 12 hours ago [-]
Did you have any personal interaction with NSA or their proxies?
tptacek 10 hours ago [-]
The point of export cryptography is not needing any personal interactions.
63 24 hours ago [-]
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.
mcpherrinm 24 hours ago [-]
(As the author of the post)
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.
dividuum 21 hours ago [-]
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.
WatchDog 20 hours ago [-]
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.
Sophira 12 hours ago [-]
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.
mcpherrinm 10 hours ago [-]
Netscape of this era predates the Subject Alternative Name :)
kyleomalley 13 hours ago [-]
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.
rustyminnow 10 hours ago [-]
I asked my AI for a rebuttal to your argument and it came up with some pretty good points.
Since inputs are more interesting than outputs I've included my prompt; you should submit it to your AI to see why you're wrong.
> I'm debating with someone online. Can you come up with a counter argument? Here's what they said: <QUOTE>
jychang 24 hours ago [-]
Probably because modern libraries dropped support for ancient insecure SSL. Backwards compatibility is really not a valued thing for that area.
CursedSilicon 24 hours ago [-]
A while back I helped a friend (read: dumped a bunch of compute power into it) brute force the SSL keys for Sega's "Phantasy Star Online" Dreamcast game.
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
“Presumably for the OP this kind of work was either outside of their realm of knowledge,”
Unnecessary? I don’t even follow the statement’s framing even if I validated the apparent nerdswipe tendency.
CursedSilicon 11 hours ago [-]
Wasn't intended as a "nerdswipe". Wrangling OpenSSL to actually work is a herculean task on a good day. Much less figuring out how to enable ancient crypto protocols within it
It's okay to "not know things". Computers are such an incredibly vast field that there's chunks of them that can simply be beyond some of us
eltondegeneres 12 hours ago [-]
> A while back I helped a friend (read: dumped a bunch of compute power into it) brute force the SSL keys for Sega's "Phantasy Star Online" Dreamcast game.
Is there anything published online about this? It looks like the Sylverant website still requires patching the game.
>>>a few odd coding decisions, such as rolling your own crypto (RNG)<<<
Let me give some context here. MaraDNS is a DNS server that’s been around for a very long time, since 2001. There has never been, in those 25 years, any security holes found having to do with the RNG code used by MaraDNS. MaraDNS originally used an AES variant for the RNG; when DJB found cache timing attacks a little over two decades ago, I revised the AES-based RNG code to minimize the impact of such impacts, making the code slower and more complicated. So, about two decades ago, I implemented a new RNG based on RadioGatún, an algorithm which isn’t vulnerable to cache timing attacks and, indeed, has no known attacks which break its cryptographic claims, even though those claims were made over two decades ago.
My code has been extensively audited by multiple AI-based security researchers, and while they found two minor issues with the DNS-over-TCP code in the recursive resolver, and a minor issue with the RFC8482 reply in the recursive resolver, no issues have ever been found with the RNG code in MaraDNS (except the issue with possible cache timing attacks I fixed myself after learning about them). [1]
In the same time period, OpenSSL has had a large number of security issues, security advisories, and so on. OpenSSL has had countless security holes and patches in the last two decades (Heartbleed, etc.); MaraDNS has had precisely 0 known issues with its RNG code in the same time period. If I had relied on OpenSSL to keep MaraDNS’s cryptography secure, it would had been exposed to many more attacks than it has, since the code I rolled myself ended up being far more secure than using the code in a third party library.
Point being, it is possible for someone to roll their own secure RNG. I wouldn’t do so in a corporate context, for the simple reason management often times puts unreasonable time constraints on developers, but for an open source project developed on my own timeline, it can be, in fact it has been very secure.
Also: I was never exposed to the Lastpass breach because, instead of using Lastpass, I rolled my own secure website password generator. [2]
Forget whether you "roll your own" or not, userspace RNGs are a bad idea. The advice to rely on getrandom or urandom is as much about the superior security properties of a kernel RNG as they are about whether you'll fuck up AES somehow.
strenholme 9 hours ago [-]
Linux kernel crypto code has resulted in security issues, e.g. CVE-2026-31431.
The advantage of using a cryptographically secure stream cipher [1] is that we only need about 128-256 bits of good entropy to generate an arbitrary large number of secure random numbers, across multiple systems (e.g. MaraDNS has a native Windows port where /dev/urandom randomness is instead done with proprietary Windows API calls). It can even give us some level of protection on systems where the OS level random API is compromised: Some people are wary of RDRAND because they think Intel might actually use an insecure PRNG for the numbers, and Coldcard Bitcoin seed generators were compromised a little over a month ago because their version of /dev/urandom was completely insecure on some of their devices.
This is CopyFail. You just provided CopyFail as evidence in favor of userspace random number generators.
nly 7 hours ago [-]
A read() on /dev/urandom on every packet isn't economical, so there's going to be some user space element to RNGion
strenholme 4 hours ago [-]
In addition to the overhead of a /dev/urandom read(), since my programs run in a chroot() sandbox, there’s the possibility that the file descriptor to /dev/urandom will no longer function—since chroot() is not part of POSIX, there’s no rigorous standard on how chroot() is supposed to behave with a given operating system.
getrandom() is another possible solution, but the problem with getrandom() is that it’s also not part of the POSIX spec, and my program needs to compile in an anally POSIX compliant system: While my programs use chroot() and setgroups(), both of which aren’t part of the POSIX spec, it has a configure time option to disable both chroot() and setgroups() so everything will compile as long as the underlying system follows POSIX.
The reason for this strict compliance with POSIX is because the changes to the C compilers (gcc and clang) between 2022 and 2026 made previous versions of MaraDNS have issues compiling everything, and, indeed, with these C23 changes to C compilers, unpatched djbdns no longer even compiles with a modern compiler. I changed everything to work with the new C23 spec, then I changed the compile flags to compile with a strictly compliant C99 compiler, but to get that to work, I had to make the program strictly POSIX compliant (with the exceptions of chroot() and setgroups()).
This way, should MaraDNS not compile in the future (remember: The post-C23 changes broke a lot of programs that used to compile just fine), it’s a bug with the compiler not following C99 and/or POSIX, and not a bug with MaraDNS.
Hence, my homegrown secure pseudo random number generator, so I can make strong random numbers while remaining POSIX compliant (we seed the PRNG before entering the chroot() sandbox). Of course, /dev/urandom is also not part of POSIX, but it’s on pretty much any modern *NIX, and trying to open /dev/urandom is not going to raise compile-time errors.
tptacek 3 hours ago [-]
I don't think trading resilience for POSIX compliance is a good call, and I don't think "strong random numbers" is at all the right way to think about this problem.
tptacek 7 hours ago [-]
I don't grant the premise that per-transaction urandom reads are likely a meaningful expense to begin with but on modern Linux getrandom is a vDSO anyways. Even before the vDSO, getrandom was fast.
The application domain where this tends to get brought up as a problem is in large-scale simulation. I have no opinion about whether getrandom is fast enough for simulation, but here we're talking about cryptographic random numbers, not simply high-quality random numbers. If you want to use something like PCG for your simulations I won't dunk on you.
smaudet 23 hours ago [-]
For what it's worth, this comment was better than the article...
When you outsource to the slop machine, you don't have anything interesting to say (usually).
throw1234567891 17 hours ago [-]
The slop machine gives answers to your questions. It hallucinates so it's recommended to verify what it says. Shit in, shit out. If you have no idea whatsoever and can't use other sources to verify claims, well, get a different job I guess.
wartywhoa23 13 hours ago [-]
Why use the slop machine then, if you already know or precognize the answer?
throw1234567891 6 hours ago [-]
Because you move faster.
CursedSilicon 23 hours ago [-]
Oh, I have *strong* opinions about the slop machine. But I try to temper them so I don't get buried by the usual "pro AI" mob
I will say that my projects have a "leading the pack" anti-AI policy [1]
Is the "pro AI" mob in the room with us? The only real mob I ever see is the one taking every chance to try to put AI down and imply its users are somehow deficient.
wartywhoa23 13 hours ago [-]
This condescending psychiatrist meme implying hallucinatory nature of entities described by one's opponent has got to stop.
prmoustache 21 hours ago [-]
You must be new here then.
CursedSilicon 21 hours ago [-]
I don't recall doing any of that. But thanks for affirming my point? :)
jimmaswell 21 hours ago [-]
Did I imply you did? I simply said I never see a "pro AI" mob, only an "anti AI" mob.
CursedSilicon 21 hours ago [-]
Let's flip it, then
Is the "anti AI mob" in the room with us right now? If not, why did you feel the need to lament it?
darkwater 18 hours ago [-]
Busy downvoting their initial comment, apparently.
jimmaswell 20 hours ago [-]
This entire comment section is almost entirely people bemoaning AI output, calling AI a "slop machine", and you posted your regressive religious screed against it as if it were something to be proud of, seemingly to the approval of others. nearly every comment section with AI involved is like this, and many comment sections where AI is not involved. It deserves pushback.
CursedSilicon 11 hours ago [-]
Ah,
So. I (and one other person) disagreed with you visibly. Ergo you felt personally called out :)
Sounds like a bit of main character syndrome
smaudet 11 hours ago [-]
You seem to be representative of this mob - I merely said that the post was bad, and welcomed some actual commentary.
There's no need for pushback, there was no technical information realy shared in the OP (no work shown or explained).
And I think the fact that the work was done by the aforementioned slop machine is telling....
But how dare I point this out, time to grab the pitchforks... bemused smile
wartywhoa23 13 hours ago [-]
People are indeed proud of remaining humans and resisting becoming AI corp appendages that are lost in slop at their own expense. Get over it. Your pushback is exactly as religious.
goalieca 1 days ago [-]
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.
adzm 23 hours ago [-]
It's possible symmetric encryption may never really be defeated by anything other than brute force. The exchange of the ephemeral key really is the important part, as you mention. Thankfully looks like we are getting closer to full adoption of post quantum TLS... but that doesn't help recorded communications before very recently. Scary thought.
This makes me wonder why we aren't using pre-shared keys as one extra layer of defense.
The idea would be to use an existing connection (established via normal TLS) to agree upon and exchange a pre-shared key. For subsequent connections, that key would be incorporated as one extra input to the key derivation function, and a new key would be derived.
This would make TLS more secure against adversaries who can break asymmetric encryption (now or later) and monitor some of your communications, but who do not have access to all of your communications. If you managed to get on an unmonitored network even once (foreign hotel WiFi, coffee shop without a wiretap), and securely establish a PSK there, all future interactions would be inaccessible to an adversary who can't break symmetric crypto.
tgsovlerkhgsel 21 hours ago [-]
> which governments around the world are just waiting to crack anonymous political speech by recording and saving for later
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.
icefo 20 hours ago [-]
Activists 10 years ago are probably still linked to interesting people the government wants to survey though, even if they are maybe less active now
utopiah 17 hours ago [-]
Activists typically aren't secretive about their actions, on the contrary they tend to be as public as they can safely be. The setup though might be, if it's to prepare an event that might be crushed down before it even take place, but then even a day later, not even a decade, to decipher would be too late and thus pointless.
oldgradstudent 17 hours ago [-]
> Punishing people a decade after the fact isn't very effective for anything.
It sends a very clear message: even if it takes a decade, we will find you and punish you.
p-e-w 17 hours ago [-]
That’s not a message activists tend to care about though. In places where speech is dangerous enough for this to matter, there are usually far more immediate threats.
suddenlybananas 14 hours ago [-]
It could potentially have blackmail material.
gosub100 13 hours ago [-]
Blackmail/ influencing elections. Find the presidential candidate's post when he was 14 and said something racist or edgy and use that as leverage or kick him out of the race.
monster_truck 13 hours ago [-]
Even if they were using the total yearly production of tapes, depending on the estimate you choose, that ~100EB is still only something like 1/50th of yearly internet traffic. Much more realistic to assume if it was worth saving in the first place they established a side channel instead.
akoboldfrying 23 hours ago [-]
The linked CADO-NFS Inria page makes no mention of GPUs, and nor does its downloads page, which makes me think that TFA's factoring was done purely on CPUs. If so, there could still be considerable speedup on the table!
The CADO-NFS page gives some benchmark results for 16 threads, suggesting the algorithm parallelises at least somewhat well.
mcpherrinm 22 hours ago [-]
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 used to work on market data feeds, which occasionally require a reference data file from an FTP to be delivered before market open before you can do anything useful with the feed.
Nothing like being on-call when the file doesn't get delivered, or fails to parse
Fortunately most feeds deliver reference data inband these days
GracefullyShot 16 hours ago [-]
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.
rbtms 13 hours ago [-]
As you probably know, the computing time in the worst case scenario for brute forcing a cryptographic key generally doubles by each bit added. That is, it would take twice the effort to brute-force 129 bits compared 128 bits.
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.
upofadown 14 hours ago [-]
This article from 2000 is about estimating what would be required to factor 1024 bit RSA:
It was a response to the idea that 1024 bit RSA was under threat at the time.
bityard 12 hours ago [-]
> I am not a cryptography expert
> How do I verify such claim?
Step 1: Become a cryptography expert. ;)
pvillano 24 hours ago [-]
That SSL report with four different automatic 'F's is an amazing punchline
teiferer 18 hours ago [-]
> 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?
mitxela 24 hours ago [-]
> 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.
mcpherrinm 24 hours ago [-]
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.
Aurornis 23 hours ago [-]
For a problem like this it doesn't matter. The part the LLM generated was a hurdle to clear on the way to the final result. Once the final result was achieved, you know the earlier step was valid enough to get there.
mitxela 14 hours ago [-]
The OP is separately advertising a list of all the keys.
joshka 23 hours ago [-]
I think you're assuming that the output of the page is LLM generated and not the process to produce the page.
tunahanfaruksav 16 hours ago [-]
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.
forgotmypw17 22 hours ago [-]
This is amazing news for people building hyper-compatible websites!
gadders 12 hours ago [-]
I womder if you could do the old Lotus Notes weak non-US Keys now, and if there are any old .nsf files floating around to be decrypted.
rootsudo 23 hours ago [-]
This is so cool, I love reverse archeology of this, having another understanding of something functional but invisible from my childhood to finally understand it and then at a later now where we can break it. So cool!
jrmg 21 hours ago [-]
In the 90s, how long did people expect it would be until consumer computer hardware would be able to do this so quickly?
Maxious 13 hours ago [-]
In Schneider's 1995 book he estimated factoring a 512-bit number would take roughly 30,000 MIPS-years (a one-million-instruction-per-second computer running for one year).
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
mcpherrinm 7 hours ago [-]
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
hashar 21 hours ago [-]
From my recalling, a few years at most. There was, and apparently still exists, distributed.net which was aimed at brute forcing DES (easy), RC5-56 bits and then RC5-64 bits by establishing a web of personal computers (via a client one had to install). Thus it was well known brute forcing was achievable in a reasonable time.
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).
LastTrain 13 hours ago [-]
It was also illegal to export software with cryptography in the early 90s, anything with keys bigger than 40 bits, so there was a lot of intentionally weak connections.
sidewndr46 12 hours ago [-]
At least in the US in the 90s, crypto was effectively required to be breakable. There expectation was this was possible at that time.
axionbraid 21 hours ago [-]
In 1999, factoring RSA-512 required roughly 292 CPU-years of work distributed across hundreds of academic machines, running for about 7 months. The community already knew it was weak -- the US export restrictions on 512-bit RSA were explicitly calibrated so the NSA could break it while casual adversaries couldn't.
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.
16 hours ago [-]
Retr0id 24 hours ago [-]
I went down the same line of thought in the past! But I guess I was less thorough with my search, I never found any certs that small.
Yes but used how? What is the exact configuration and details for reproducing this?
mcpherrinm 7 hours ago [-]
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:
All run in a tmux to keep it alive for the few days, of course.
excalibur 24 hours ago [-]
> 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.
The planet has a lot of people.
MrDOS 13 hours ago [-]
Are very many of them time travellers?
jasomill 7 hours ago [-]
No, but some are retrocomputing enthusiasts who might occasionally run vintage browsers on non-Y2K compliant systems. The cert in question has a "not before" date in 1998, and Netscape 4.51 hails from around same time.
Probably zero doing anything worth MitMing, though.
Sophira 11 hours ago [-]
You'd be surprised.
andytratt 23 hours ago [-]
lol nice job Marc Andreesen
Neat_comfort007 10 hours ago [-]
[flagged]
rwissinger 13 hours ago [-]
[flagged]
ggm 1 days ago [-]
The cost per bit is a doubling in time. So factoring a 512 RSA, compared to a 1024 RSA is significantly cheaper. The OP used contemporary hardware to do this. so, we'd have to ask if the orders of magnitude improvement in tech (QC aside) would permit 1024 in tractable time. I tend to no, but I appreciate there are other points of view. And of course, the belief that one day we can apply Shor with success exists. At which point the question is moot. Not that Shor does not itself demand significantly more stable gates, per extra bit of RSA. I always wonder why people don't look at the trend line in stable QuBits and the trendline in cost of RSA. Do the lines intersect?
Remember, Shor is like a coded gate level algorithm expressed as sequences of interconnected stable QuBits. So, if you double the cost for each RSA bit you add, its not "nothing" in terms of how you wire the rig.
(not a cryptographer, or a QC person so I expect to be hit by a very cold but stable quantum clue-by-four shortly. Maybe they have to hit me 1 million times, to confirm I'm hit. Its statistics.)
mcpherrinm 1 days ago [-]
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.
WhiteDawn 20 hours ago [-]
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…
throwawayk7h 24 hours ago [-]
out of curiosity, how long would 2048-bit RSA take to factor?
mcpherrinm 24 hours ago [-]
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.
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.
mitxela 11 hours ago [-]
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.
upofadown 10 hours ago [-]
What does the speed of RSA have to do with anything?
mitxela 8 hours ago [-]
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.
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.
entrope 24 hours ago [-]
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.
mitxela 24 hours ago [-]
Doubling per bit is for symmetric encryption, where no attack better than brute force is known. RSA can be attacked using much faster techniques than brute force.
ColinWright 17 hours ago [-]
Can you point at some papers or articles that talk about attacks specifically on RSA? I've done a search and have a few references, but I'd be interested to know if you have any particular examples in mind.
I know that factoring (which attacks RSA) is sub-exponential, and I know that implementations of RSA (bad choices of primes, timing attacks, etc) can have weaknesses ... I'm just interested as to whether you have something else in mind.
That's referring to attacking the factoring problem, which is one method of attacking RSA, and as I said is known to be faster than exponential, but it felt like the comment to which I was replying was talking about something other than just faster factoring.
I know there are other attacks on RSA, I was interested to know if the poster to whom I was replying knew of any others (other than factoring, which is kinda obvious). After all, I said:
> I know that factoring (which attacks RSA) is sub-exponential, ...
In practice it was confined to specific TPM modules, but in principle it shows how one flaw in the RNG can jeopardize the whole system.
I also remember seeing a similar vuln in certificates where an attacker _generated_ millions of certs and was able to somehow get the private cert by trying every possible seed for the RNG. (Like seeding every second from 2003-2011 for example, then generating a cert with it). I know I'm getting major parts of this wrong but it conveys the general idea.
mitxela 11 hours ago [-]
Return of Coppersmith Attack is, as the name suggests, a really old attack whose fix has been known for a decades but was missed in certain newer implementations. It does indeed underscore how RSA is tricky and you shouldn't do it yourself. Everything has to go right for it to be secure, unlike something like AES which doesn't have such subtle failure modes.
ColinWright 12 hours ago [-]
Super ... thank you.
rcxdude 1 days ago [-]
There are techniques to speed up the search for RSA keys quite significantly: they don't scale as with a pure brute force search, nor with a very useful rule of thumb (it's not even the case that doubling the RSA key length doubles its effective security, it's actually a fair bit less than that).
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.)
After that, open source efforts to rebuild the entire browser and mail client took years as XUL and Gecko were being built as very generic reusable components, opening up the space for competition to spring up. On top of that, Microsoft leveraged the Windows moat, including IE 3.0 and later 4.0 as the basis of Windows "97" (95 something-something) and 98, along with ActiveX push. By the time legal systems caught up with the practice of bundling a browser into a dominant OS, Netscape and Mozilla were toast.
Everything from there on was an uphill battle, and when KHTML was turned into WebKit by Apple, and adopted by Google for Chrome, there was also an open source engine (or two) supported by infinite money.
That's at least how I remember it, but you are welcome to fact-check me on any of those since this is now 20-30 years ago.
Suppose you live in South America, register a domain from a registry in Canada and then have users accessing it from Ukraine. Are we going to give every local government a global root certificate? Have a single one in California or Texas that every other country is somehow forced to use? Or make it so people in Europe can't access sites in Asia and vice versa?
The existing system is more than the usual amount of messed up but that seems like one of the things that could actually make it worse.
Just publish a public key in your DNS TXT records. ACME is just that anyways but with extra (pointless) steps.
The whole SSL certificate grift is just a way to extort money out of nothing.
DNSSEC is probably not even used, though I never checked.
Eg. as a domain owner, you will put a cryptographic hash into your DNS zone so a CA can validate you have control over it, and then issue a different cryptographic hash derived from their private key, and browser will use their public key to validate this cryptographic hash (TLS cert) is valid.
So we could simply push public key into a DNS zone, and browsers could use it to decrypt the traffic encrypted by the private key from the server hosted under that DNS name: no CAs needed, similar to SSH except the DNS-ownership-implied-trust component.
"Extended validation" certificates involved a lot more (in theory, checking true ownership, business address, physical presence, etc), but nobody really cares about these, and with the push to automated renewal and 45-day expiration dates by 2028, it's going to make even less sense.
Edit: I realize now that you may be referring to the fact that MITM DNS server can inject a different public key in there and thus DNSSEC is required — you are absolutely right, and this is a good and important point.
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.
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.
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.
From my prospective, the outputs of a bot aren’t the interesting bits, it’s the input prompt that should warrant more attention.
Since inputs are more interesting than outputs I've included my prompt; you should submit it to your AI to see why you're wrong.
> I'm debating with someone online. Can you come up with a counter argument? Here's what they said: <QUOTE>
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...
“Presumably for the OP this kind of work was either outside of their realm of knowledge,”
Unnecessary? I don’t even follow the statement’s framing even if I validated the apparent nerdswipe tendency.
It's okay to "not know things". Computers are such an incredibly vast field that there's chunks of them that can simply be beyond some of us
Is there anything published online about this? It looks like the Sylverant website still requires patching the game.
https://sylverant.net/connecting-to-sylverant/
https://github.com/patapancakes/dreamconstraint
Absolutes like this aren’t absolutely true.
It’s interesting because in a related comment, someone claimed that I was “rolling my own crypto” https://news.ycombinator.com/item?id=37368245
>>>a few odd coding decisions, such as rolling your own crypto (RNG)<<<
Let me give some context here. MaraDNS is a DNS server that’s been around for a very long time, since 2001. There has never been, in those 25 years, any security holes found having to do with the RNG code used by MaraDNS. MaraDNS originally used an AES variant for the RNG; when DJB found cache timing attacks a little over two decades ago, I revised the AES-based RNG code to minimize the impact of such impacts, making the code slower and more complicated. So, about two decades ago, I implemented a new RNG based on RadioGatún, an algorithm which isn’t vulnerable to cache timing attacks and, indeed, has no known attacks which break its cryptographic claims, even though those claims were made over two decades ago.
My code has been extensively audited by multiple AI-based security researchers, and while they found two minor issues with the DNS-over-TCP code in the recursive resolver, and a minor issue with the RFC8482 reply in the recursive resolver, no issues have ever been found with the RNG code in MaraDNS (except the issue with possible cache timing attacks I fixed myself after learning about them). [1]
In the same time period, OpenSSL has had a large number of security issues, security advisories, and so on. OpenSSL has had countless security holes and patches in the last two decades (Heartbleed, etc.); MaraDNS has had precisely 0 known issues with its RNG code in the same time period. If I had relied on OpenSSL to keep MaraDNS’s cryptography secure, it would had been exposed to many more attacks than it has, since the code I rolled myself ended up being far more secure than using the code in a third party library.
Point being, it is possible for someone to roll their own secure RNG. I wouldn’t do so in a corporate context, for the simple reason management often times puts unreasonable time constraints on developers, but for an open source project developed on my own timeline, it can be, in fact it has been very secure.
Also: I was never exposed to the Lastpass breach because, instead of using Lastpass, I rolled my own secure website password generator. [2]
[1] https://samboy.github.io/MaraDNS/webpage/security.html
[2] https://github.com/samboy/PassGen
The advantage of using a cryptographically secure stream cipher [1] is that we only need about 128-256 bits of good entropy to generate an arbitrary large number of secure random numbers, across multiple systems (e.g. MaraDNS has a native Windows port where /dev/urandom randomness is instead done with proprietary Windows API calls). It can even give us some level of protection on systems where the OS level random API is compromised: Some people are wary of RDRAND because they think Intel might actually use an insecure PRNG for the numbers, and Coldcard Bitcoin seed generators were compromised a little over a month ago because their version of /dev/urandom was completely insecure on some of their devices.
[1] Yes, libsodium supports them: https://libsodium.gitbook.io/doc/advanced/stream_ciphers
getrandom() is another possible solution, but the problem with getrandom() is that it’s also not part of the POSIX spec, and my program needs to compile in an anally POSIX compliant system: While my programs use chroot() and setgroups(), both of which aren’t part of the POSIX spec, it has a configure time option to disable both chroot() and setgroups() so everything will compile as long as the underlying system follows POSIX.
The reason for this strict compliance with POSIX is because the changes to the C compilers (gcc and clang) between 2022 and 2026 made previous versions of MaraDNS have issues compiling everything, and, indeed, with these C23 changes to C compilers, unpatched djbdns no longer even compiles with a modern compiler. I changed everything to work with the new C23 spec, then I changed the compile flags to compile with a strictly compliant C99 compiler, but to get that to work, I had to make the program strictly POSIX compliant (with the exceptions of chroot() and setgroups()).
This way, should MaraDNS not compile in the future (remember: The post-C23 changes broke a lot of programs that used to compile just fine), it’s a bug with the compiler not following C99 and/or POSIX, and not a bug with MaraDNS.
Hence, my homegrown secure pseudo random number generator, so I can make strong random numbers while remaining POSIX compliant (we seed the PRNG before entering the chroot() sandbox). Of course, /dev/urandom is also not part of POSIX, but it’s on pretty much any modern *NIX, and trying to open /dev/urandom is not going to raise compile-time errors.
The application domain where this tends to get brought up as a problem is in large-scale simulation. I have no opinion about whether getrandom is fast enough for simulation, but here we're talking about cryptographic random numbers, not simply high-quality random numbers. If you want to use something like PCG for your simulations I won't dunk on you.
When you outsource to the slop machine, you don't have anything interesting to say (usually).
I will say that my projects have a "leading the pack" anti-AI policy [1]
[1] https://wiki.cursedsilicon.net/wiki/AI_Policy
Is the "anti AI mob" in the room with us right now? If not, why did you feel the need to lament it?
So. I (and one other person) disagreed with you visibly. Ergo you felt personally called out :)
Sounds like a bit of main character syndrome
There's no need for pushback, there was no technical information realy shared in the OP (no work shown or explained).
And I think the fact that the work was done by the aforementioned slop machine is telling....
But how dare I point this out, time to grab the pitchforks... bemused smile
Looks like 70% of cloudflare requests are using post-quantum TLS! https://radar.cloudflare.com/post-quantum
The idea would be to use an existing connection (established via normal TLS) to agree upon and exchange a pre-shared key. For subsequent connections, that key would be incorporated as one extra input to the key derivation function, and a new key would be derived.
This would make TLS more secure against adversaries who can break asymmetric encryption (now or later) and monitor some of your communications, but who do not have access to all of your communications. If you managed to get on an unmonitored network even once (foreign hotel WiFi, coffee shop without a wiretap), and securely establish a PSK there, all future interactions would be inaccessible to an adversary who can't break symmetric crypto.
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.
It sends a very clear message: even if it takes a decade, we will find you and punish you.
The CADO-NFS page gives some benchmark results for 16 threads, suggesting the algorithm parallelises at least somewhat well.
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...
Nothing like being on-call when the file doesn't get delivered, or fails to parse
Fortunately most feeds deliver reference data inband these days
> 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.
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.
> How do I verify such claim?
Step 1: Become a cryptography expert. ;)
What better reason is there to do something than it being fun?
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.
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
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
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.
Install CADO-NFS per upstream directions.
Get the number you want to factor. I just did this in a python repl, something like:
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:
All run in a tmux to keep it alive for the few days, of course.The planet has a lot of people.
Probably zero doing anything worth MitMing, though.
Remember, Shor is like a coded gate level algorithm expressed as sequences of interconnected stable QuBits. So, if you double the cost for each RSA bit you add, its not "nothing" in terms of how you wire the rig.
(not a cryptographer, or a QC person so I expect to be hit by a very cold but stable quantum clue-by-four shortly. Maybe they have to hit me 1 million times, to confirm I'm hit. Its statistics.)
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.
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.
2048 Bit RSA and the Year 2030 https://articles.59.ca/doku.php?id=em:20482030
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.
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.
I know that factoring (which attacks RSA) is sub-exponential, and I know that implementations of RSA (bad choices of primes, timing attacks, etc) can have weaknesses ... I'm just interested as to whether you have something else in mind.
Thx.
Reference to a scientific paper is given: https://www.ams.org/notices/199612/pomerance.pdf
I know there are other attacks on RSA, I was interested to know if the poster to whom I was replying knew of any others (other than factoring, which is kinda obvious). After all, I said:
> I know that factoring (which attacks RSA) is sub-exponential, ...
www.techtarget.com/cybersecurity/tip/The-ROCA-vulnerability-How-it-works-and-what-to-do-about-it%3famp=1
In practice it was confined to specific TPM modules, but in principle it shows how one flaw in the RNG can jeopardize the whole system.
I also remember seeing a similar vuln in certificates where an attacker _generated_ millions of certs and was able to somehow get the private cert by trying every possible seed for the RNG. (Like seeding every second from 2003-2011 for example, then generating a cert with it). I know I'm getting major parts of this wrong but it conveys the general idea.