mcpherrinm

Doing end-to-end cryptography is hard enough to get right. Adding multiple devices to the mix makes it even harder.

So it's an explicit trade-off, made to keep your communication safer. Signal, in general, is uncompromising about privacy and about keeping metadata out of their hands.

This exists in Firefox at least, but I don’t think it’s easily exposed in the UI

Assuming it works the same way as their MySQL product, Vitess:

The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be.

I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)

I think "very straightforward" is vastly overselling how easy editing OSM is.

It feels like editing a database, without any affordances for easily making common updates.

If the hours of a store are wrong on Google Maps, I just upload a photo of their store, and it'll be corrected quickly.

On OSM, well, most things are out of date. There's no simple 'update this business' flow, just a database editor. And a map that feels like I could break anything by clicking in the wrong spot.

OSM is a cool project, but it isn't straightforward. And unlike Google and Apple maps, most of the businesses in my area are years out of date, so I can't effectively use it to find information either, so I just don't have any reason to interact with it. Plus no aerial/satellite/streetview imagery, which I understand is probably infeasible, but ultimately it just means OSM is a niche product that won't replace Google.

So yeah, I'm propping up Google, but I get way more benefit out of it than having an open data set used to power Amazon's delivery driver routes or whatever.

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:

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

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

Netscape of this era predates the Subject Alternative Name :)

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.

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.

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

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.

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.