Hacker News

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!

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!

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.

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.

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.

It's easy enough to apt upgrade, and curl shows it's not vulnerable.

But what about python pip and node and bun which bundle their own certs?

And then you'll have a compiled binary like Claude Code, which was built with bun, and has its vulnerable certificates bundled in, ignoring the system certs.

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.

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.

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.

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.

>yandex-station-lite

At last, russians got better at installing wiretaps. Reminds me of the old joke that goes "How do you know there is a soviet made bug installed in your home?

There is an extra wardrobe."

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

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!

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.

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.

This is everyone's first pitch for why DANE would improve the WebPKI. But it doesn't make sense as risk management. It assumes that the most important TLD operators, .COM especially, are trustworthy. But we know .COM is not trustworthy, at all. And it gets worse when you leave the US. In much of the world, state organizations have explicit de jure control over all the popular top level domains.

This is a simple point but there's something subtler underneath it. Strict name constraints are an obvious seeming improvement to the WebPKI. I like them too. but eMudhra isn't just an Indian sovereign CA; it's an important global commercial vendor. On the other thread about this incident, 'agwa pointed out that an eMudhra subsidiary does a lot of the certificates for US universities.

You're still going to end up with the same concentrations of risk, because large CAs are going to want to issue in the most popular domains.

Don't get me wrong, anything that ratchets up the difficulty of running a CA (without unduly burdening LetsEncrypt) is a positive as far as I'm concerned. I'm just saying these are hard problems.

Either that or it's running PHP

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

I see you love technology.

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

If the application uses p11-kit, or a TLS library that uses p11-kit such as OpenSSL, NSS, or GnuTLS, then Flatpak should automatically give it access to the host system's CA certificates.

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.

It seems that somebody / something only created a single byte of randomness for each certificate.

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.

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

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

They clearly used the one from XKCD.

https://xkcd.com/221

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

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

It’d be absurd to believe nobody tested these, and that no individuals involved in relevant standards bodies were aware of this weakness.

If you've got the compute power, it's easy enough to have a go at it!

“4”

hey chatgbg what is a “private key”

Isn't 4 simply 2 bits?

Silly 2-bit outfit.

Maybe it's 3 bits.

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/

Scary perhaps, but not surprising. Most IT "audits" and security reviews are little more than performative box checking activities. I'm sure their documentation and screenshots looked great.

Yeah, this would work.

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

My impression is "why" is political, with regulations like EU's eIDAS and other national digital sovereignty efforts setting the rules. It's not even WebTrust that's the target in most cases, it's the ETSI EN 319 series and ISO 21188.

Is it possible to convince the EU to say that, no, each one of your 27 member states isn't allowed to have a PKI? I don't think so.

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.

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

Apple has blocked the intermediates, so updating is good enough to resolve it for you.

You also need to block access to the approved CT list until it fails open after 70 days.

This is assuming the CT logs no longer issue SCTs for these CAs. If they do then you just need to the CT dance and publish that certificate there.

Of course this assumes the app/device isn't using certificate pinning.

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.

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

All the numbers were under 256. Surely they did.

This wasnt malice its was laziness.

They literally were too lazy to type more than just a single '4'.

https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

The real problem the CAs try to solve is, basically, being a trusted middleman who vouches for other certificates.

The first time you connect to google.com in your browser and get the google.com certificate, your web browser has to decide whether or not to trust that cert. It would be very complicated if every website on the internet had to prove its identity via some sort of out of band process, so web browsers, operating systems, etc all ship with a collection of trusted, institutionally-important certificates which are allowed to vouch for other certificates that aren't yet known to the browser, OS, etc.

Your browser (or whatever HTTPS client) basically says "I've never seen this certificate before, but Lets Encrypt (or Digicert or whoever) says they trust it and we trust Lets Encrypt, so we can treat it as trusted". You as a user are trusting that whatever verification/validation process the CA does is at least good enough to ensure that the owner of the domain is the entity giving you a certificate for that domain.

This is obviously not a perfect system. These CAs can be compromised and break the trust, and they have various levels of validation of the people and companies who come to them and ask to be included in their vouching network, etc. But its a compromise to make sure that users can connect to a wide variety of internet sites, using encryption, without needing to somehow decide whether they themselves trust the certificate provided by the website.

The most important thing to remember is that in most cases the CA is not vouching for the quality or integrity of the website - they are just vouching for whether the person/group who controls the domain/server is also the person/group providing the certificate for encrypted communication with the website. Its a protection against MITM attacks and snooping, not a protection against phishing or anything else that might happen once the connection is established.

I have an older blog post that goes in to a little detail on what a CA is and how it works: https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg...

Literally the tutorial they used

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

Hey what's wrong with Passkeys?!

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.

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?

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

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.