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

Yeah. Vitess does have some options for atomic cross-shard commits using an additional database to track two-phase commits, but that's expensive so you probably want to avoid that. https://vitess.io/docs/25.0/reference/features/distributed-t...

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

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

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 learned about <https://en.wikipedia.org/wiki/2011_T%C5%8Dhoku_earthquake_an...> from alarms like this, as sales in Japan almost entirely stopped.

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.

She posted a video of her food loadout on instagram. It looked like a lot of dehydrated meals, and also a lot of peanut butter and tortillas.

Here's a video of a day's food: https://www.instagram.com/reel/DZd8V8BtGbH/

She said she has two desalinators - one hand-pump and another electric, plus emergency water bottles to last a few days.

She's got a lot of content posted on Instagram and TikTok, which includes packing food, videos of the boat inside and out, etc.

https://www.instagram.com/yourowkelsey/reels/

https://www.tiktok.com/@yourowkelsey

Here's a cabin tour: https://www.tiktok.com/@yourowkelsey/video/76461920366635778...

So, in this case it wasn't correct to do so, but there is actually a current algorithm which uses floating point: Falcon (aka FN-DSA).

https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-... talks about FN-DSA and has a section about how it's require to hand-implement floats to get constant-time operations.

The underlying context is the US government only wants to buy systems which support pure post-quantum cryptography for use on top-secret networks, as part of the requirements of (via its Commercial National Security Algorithm Suite 2.0 standard).

So all the companies who want to sell anything using TLS to the government want to standardize this, so they can be CNSA2 compliant.

Everyone already supports this in major libraries; but some folks feel they need an IETF RFC specifying it.

(I don't have to comply with CNSA2 so I might have details slightly off)

If a key is breached, the certificate can be revoked, but that revocation goes away once the certificate is expired.

Expiry is a pretty fundamental part of the security model of certificates.

It's the list here:

https://docs.adyen.com/plugins#built-by-adyen

The best introduction to verifiable indexes I know of offhand is https://www.youtube.com/watch?v=gfrXTgmbS1s and https://github.com/transparency-dev/incubator/tree/main/vind...

Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised.

There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it.

CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, you have one issuing log, along with signatures from other "witnesses" which monitor and mirror log integrity. Those co-signatures are validated when checking the certificate.

Thus the witness network makes it much harder for logs to fork, as you can't present a forked view to just the client. You also need to present it to a witness. And it'll be much easier for folks to check all the witnesses are in sync.

Monitoring the MTC logs will be easier than CT, as they'll actually be smaller than CT for a few reasons. At least for the initial version, there won't be a better way to monitor for mis-issued certificates for a particular domain than linear scanning all certificates, but that's a problem being worked on for both CT and MTC, called "verifiable indexes".

On Linux and similar systems, I'm hoping github.com/rustls/upki will handle landmark distribution, and that non-browser clients can use that. Of course Rustls will support their own project, but I'm hopeful other TLS stacks do too. Ubuntu announcing they're deploying it should help with that.

On other OSes (like Mac OS and Windows), there's also OS-level services which could support this.

It would be a shame if we end up with a bunch of copies of this data, so I think a shared OS service is the only reasonable approach.

The hardest part is going to be smaller embedded systems.

Great question! Of course, we'll continue to provide more information as we firm up more details. This is an area that's not locked down yet, but I can give a sneak preview of what it might look like.

We expect batches to be produced quickly, on the same order of magnitude as current CT logs - somewhere in the 0.5s to 5 second range. This is an existing problem since (at least some) CT logs do the same batched behaviour.

Now, there is a catch with MTCA: That gets you a "standalone" certificate, which works just like a certificate does today. But it's big, still. To get the new, small certificates (landmark-relative), you will have to wait for the next landmark. Based on current planning and discussions with Chrome, we expect that to be hourly for short-lived certs, and 4 hours for longer-lived certificates.

So you'll get a big cert instantly, but you might have to wait an hour or 4 to get a certificate. So your new website can be online quickly, but with some downsides until you get the small landmark-relative cert.

(I work at Let's Encrypt)

OpenSSH's Damien Miller has https://datatracker.ietf.org/doc/draft-miller-sshm-mldsa44-e... defining [email protected] which seems more likely given the authorship.

Even without DNSSEC, the CAA record approach can help, as it requires MITMing between the CA and the DNS server, which may be harder in some cases than just MITMing a target site.

There’s some upcoming attempts at transport security for authoritative DNS servers which might help too: https://datatracker.ietf.org/doc/html/draft-hoffman-deleg-se...