Live data from Hacker News

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

mcpherrin.ca

111–120 of 131 posts

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

#111

Earlier quoted context omitted.

“Rolling your own crypto libraries is always a bad idea” 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…

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.

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.

[1] Yes, libsodium supports them: https://libsodium.gitbook.io/doc/advanced/stream_ciphers

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

#112

Earlier quoted context omitted.

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.

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…

This is CopyFail. You just provided CopyFail as evidence in favor of userspace random number generators.

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

#113

Earlier quoted context omitted.

Its a shame public internet is npt viewed as a public utility

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 vers…

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.

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

#114

Earlier quoted context omitted.

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 vers…

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.

Ok, but now you need to trust DNSSEC.

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

#115
post #93

Earlier quoted context omitted.

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.

What does the speed of RSA have to do with anything?

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.

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

#116

Earlier quoted context omitted.

“Rolling your own crypto libraries is always a bad idea” 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…

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.

A read() on /dev/urandom on every packet isn't economical, so there's going to be some user space element to RNGion

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

#117
post #77

> 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.

Are very many of them time travellers?

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.

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

#118
post #116

Earlier quoted context omitted.

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.

A read() on /dev/urandom on every packet isn't economical, so there's going to be some user space element to RNGion

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.

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

#119
post #32

Earlier quoted context omitted.

The author mentions CADO-NFS right in the article: https://cado-nfs.gitlabpages.inria.fr/

Yes but used how? What is the exact configuration and details for reproducing this?

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:

    ./cado-nfs.py 10754123440737946604182274398563307850262685121187325065132187145895199633213947273310647001521000121802425390193123548314361970563322281259804690831526167 -t 32 --workdir /data/cert1

All run in a tmux to keep it alive for the few days, of course.

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

#120

I owned the "broker FTP" service at a hedge fund. 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/180957…

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

Post reply on HN