Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds

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

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

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!

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.

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

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.

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

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.

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

https://xkcd.com/221/

CA has the key, if it wanted to give someone a backdoor, it wouldn't issue a weak key.

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 suggestion seems to be a symptom of thinking different TLDs represent different levels of trustworthiness... which hasn't been the case in ages

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.

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.

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

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

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

I wonder how they would argue in court, like "I guess we were unlucky huh ?"

https://xkcd.com/221

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.

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

hey chatgbg what is a “private key”

Silly 2-bit outfit.

Maybe it's 3 bits.

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

https://xkcd.com/221/

They don't. They use the OS certificate store, which on all platforms has already had this certificate revoked from it.

These runtimes are just doing this as a secondary precaution to deliver the revocations to anyone paying attention to version numbers for their runtime but not their OS. It's a bit of an odd approach, and for most of these projects it's their first time ever doing such a thing, but there's no big issue with it as long as it doesn't encourage complacency and is only applied to truly revoked certificates.

You are thinking of Java, which does actually have its own certificate store. Java users are familiar with how wacky this is, so there have been 3rd party attempts at a cleaner solution, such as the way RHEL keeps the Java certificates in sync with the system certificates.

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

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.

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

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.

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

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

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.

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

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.

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.