Devices that are smart enough to talk to the internet but not smart enough to let the user install their own certs should not exist.

If you just take them offline you can do this without having to rush.

Just change your WiFi password, don’t give them the new one and don’t update them lol.

These devices are already very weak and many of them even do non-TLS updates with no signing check anyway.

If it has been so weak already, it can't be weaker.

Just imagine how much stuff you're going to be able to MiTM now!!

Some of them seem to do some cert pinning

> > Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...

The interesting question is, how many of these devices will have the compromised CA root certificate in place?

Oh and another thing is problematic, many a Java app ships with its own keystore.jks if it needs to trust some privately hosted endpoint, and that keystore.jks may or may not contain the compromised CA root certificate... updating the OS will not catch this kind of stuff.

I must say, if I was writing a password cracker, I probably would not think to actually start at "1".

> https://github.com/google/paranoid_crypto

This repository was archived by the owner on Aug 19, 2026. It is now read-only.

I guess now that we've checked, nobody will ever make a mistake like this again so we don't need this anymore? :)

I'm guessing this is the code:

https://github.com/google/paranoid_crypto/blob/main/paranoid...

I have to be honest, that hasn't stopped me from trying!

Certificate transparency requirements effectively take the power away from certificate authorities.

They instead place the burden on individual webmasters again to actually verify that nobody has been falsely issuing for their domains. There are also some new vulnerabilities about CT logs who might be malicious.

In retrospect, not having a tiny competency check may have been an oversight.

That really depends how you define "trusted certificate authorities".

If you're talking about root certs then it's almost 350 currently trusted by at least one major operator.

If you include intermediates, you're talking more than 3,600!

How are they trusted if they can just generate any key they like in their back room?

Correct, we only need zero.

or, perhaps you need more so that one being stupid doesn't effect so much.

Yeah this is absolutely possible, and while they are a few good opportunities like this, it also means that someone else can decrypt all of your traffic in the same way.

Yeah, it's happening in the wild already. Seen more cases like that.

1. They could do this now, the implementation exists publicly, but I think it would be better at the OS level like upki for revocation: https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki...

2. I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.

1 already exists. You don't check the ctlogs; the ctlogs as their signed timestamp to the certificates. All you need to verify that a certificate has been published is to verify the timestamp signatures.

In their defense, they were probably targeting the Mersenne prime 2^2 - 1 and just made a typo.

ok, it's joke. but for those who don't get it: elliptic curves don't need primes

It’s really impressive no one caught their three previous private key values

They should have gone with 57. Everyone knows it's prime.

https://xkcd.com/221/

it doesn't have to be and it actually never is: this isn't RSA, it's an elliptic curve algorithm. if you'd have read the article, you'd have understood this

The number 4 is very famous.

https://xkcd.com/221/

Hey, that's the same combination I have on my luggage!

It's not that 4 isn't a valid seed (though insanely unlikely) it's that once I know your values weren't picked randomly because I guessed one of them I can easily figure out the others.

In this case one cert gets defeated and you go the odds of that number being that low are 2^-384. Essentially impossible if it were randomly selected. It's much more likely you didn't choose that at random so I start guessing a bunch of other low numbers for your other certificates and find them quickly.

Imagine you have a 3 digit PIN code. That’s 1,000 options to brute force. If you remove 000-009 as “too weak”, you still have 99% of the search space available. These numbers scale favorably as the private key size gets bigger.

In short, raising the floor doesn’t really hurt the search space meaningfully.

Yes, what matters is the size of the range, not the bounds on the range. Also keep in mind that in some cases private keys are not uniformly sampled from a range of integers; for example RSA keys, which are sampled from prime numbers.

More generally, it is common to sample a bit string and use that as a seed for a PRG, from which the private key is generated. So in that case the range is [0, 2^k] and what matters is the quality of the randomness. Unfortunately high-quality randomness is not always available, especially for embedded devices and rack-mounted "appliances."

You are technically correct, the best kind of correct! Though I have a feeling we'll never see a 384-bit CSRNG generate 352 0-bits in a row in this Universe's lifetime.

That said, a sanity check on the value somewhere in the code would indeed have prevented this.

IIRC in RSA the key, a prime number, is selected between 2^(bits-1) and 2^bits, or iow it always starts with a 1₂.

Either that or it's running PHP

I see you love technology.

You'll know this evening when it demands $10 to release your meal.

The more cynical among us think that is part of it. Remember when Bush Jr. became a bumbling idiot for a few years?

They clearly used the one from XKCD.

https://xkcd.com/221

I suspect that they read the article last Friday about Claude finding the origin of the ECDSA constants. That was only a few hours before Google received the vulnerability report.

The two cases are very similar. The only difference is that the weak randomness was harmless in the earlier story, and here it’s devastating.

Of the thousands of people bored with a swarm of AI agents, is it not plausible that somebody would just say "hey, let's do a vibe check to see whether any CAs are trivially crackable"?

> and presumably nobody would try to brute-force a private key.

Why not? There are examples of RNGs providing very poor entropy which might be a reason to check it (looking at you Sony).

This question seems to be answered in another comment now: https://news.ycombinator.com/item?id=50180284

“4”

hey chatgbg what is a “private key”

Isn't 4 simply 2 bits?

Silly 2-bit outfit.

Maybe it's 3 bits.

> promise security and.. make a profit

Some would argue the inherent moral hazard makes these opposing outcomes that cannot be achieved simultaneously.

Like a web-of-trust model?

Artisanal cryptography. Hand-picked private keys salted with organically sourced nonces.

My bet is on one of

- A sequence number being accidentally used as the private key or

- The private key being generated securely but then accidentally truncated to 8 bits (e.g. writing a single char into a zeroed buffer when you should've memcpy'd from a char*).

The sequence number idea is supported by the fact that two of the G3B private keys are consecutive numbers. I ran a quick Monte Carlo simulation and if I got it right, sampling 8 keys from [0,255] uniformly at random (as in the truncation scenario), you'd expect them to contain 2 consecutive numbers only about 18% of the time.

There's a beginning of an explanation in the mozilla bugrepor thttps://bugzilla.mozilla.org/show_bug.cgi?id=2083449

A long time ago one time pads used to be chosen by hand by women picking numbered lottery balls out of a spherical tumbling machine on a table.

The fact that there are more than the "4" one, and all the low numbers are below 384 (384 being the bits for private key) makes me think whoever was creating these thought "Oh a random number between 1-384" let me choose... 4! (156, 230, 115, 56, 66, 237, 155)...

https://xkcd.com/221/

“espionage” would involve a private key shared with the three-letter agencies, not a key anyone could crack in seconds

Count yourself lucky - compared to Claude's prose, this is fairly readable.

It reads fine to me. If it is AI, I'd like to know which one so I can use it too.

Given the usefulness of this to anybody who knew about it between the ceremony and now - assume malice.

And an equal amount of stupidity in the whole ecosystem, apparently there are no "unit-tests" for trivial failure modes, like 8 bits of entropy, before adding a CA to the trusted list.

What next, googling the public key finds a 2 year old pastebin with the private key?

Any sufficiently advanced malice is indistinguishable from stupidity.

You can add the intermediate CA to your block list, presumably the distros will do this

With the speed of vibe coding.. I'd expect the "Reverse Engineer Anything" folks to come out with a "Man in the Middle Anything" app by lunch

It's a valid question at this point.

All the numbers were under 256. Surely they did.

Another place to search for private key candidates would be the outputs of various common PRNGs when they have been seeded with a timestamp (for all timestamps in, say, the past 20 years).

These would look like nice random values (unlike the ones that were recently compromised), but they would be trivial to generate by anyone who knows the initial inputs (PRNG algorithm, seed, maybe starting byte position, etc.).

These are intermediate roots, signed by trusted root certs, so the trust from your OS or browser is implicit to the roots it trusts.

Literally the tutorial they used

I think this might be proprietary source code, did you get permission to share this?..

It's an interesting idea, but how would a user make that decision on who to trust? As in, what 'things' could we look at to make that call?

Doesn't ACME+CT solve this threat?

Can't lose your key if it's easy to remember!

I'm not so sure. If you wanted to be deliberate, you'd choose a plausible value that you could control.

No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.

Makes no sense.

If it was deliberate, one would use keys that only the person abusing it has. Not keys everyone can guess if they get a hint.

Why would it be?

I would be shocked if this was anything other than a bug. A CA already has the power to issue MITM certificates, so what reason would a CA have to deliberately generate bad keys?

In all likelihood it is code that reads 1 byte from /dev/random, or reads 32 bytes but writes it into a 1 byte array, or something to that effect.

Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.