"I've had more than a few emails asking on how this was discovered. The simple answer is: https://github.com/google/paranoid_crypto
Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far."
https://groups.google.com/a/mozilla.org/g/dev-security-polic...
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? :)
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 violated that trust.
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.
"As a rule, strong feelings about issues do not emerge from deep understanding."
And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.
There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.
Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.
(Moving the PKI into DNS does not remove it, it just moves it around.)
Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there.
One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust.
We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet.
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
EDIT: seems its already happening? https://x.com/otomir23/status/2112697830687047918
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.
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
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).
It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?
The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".
It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
Some would argue the inherent moral hazard makes these opposing outcomes that cannot be achieved simultaneously.
8 bits is crazytalk!
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.
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
What next, googling the public key finds a 2 year old pastebin with the private key?
Don't they even test script changes on a staging server? How could there be such a script error in production that was not caught in testing/staging?
This sounds very like a fundamental organization error, not an innocent whoopsie. It should lead to a permanent ban of the organization.
They explicitly said they wanted to export the keys from the HSM; the keys were intended for USA/Europe (for sovereignty reasons) but were never actually used.
It seems the HSM itself worked, their ceremony around wrapping/unwrapping didn't.
I'm sure the Utimaco's used (haven't worked with one) also allow all slots to contain the same name or keys with the same name and the device always selecting the first one if you only provide the name and not the slot ID or token identifier. Don't ask how I found out the hard way.
So using an HSM in the first place is a security theater. Or that this HSM isn't really an HSM since it allows for export of the private key.
The trusted enclave in a MacBook is more secure than this HSM.
The write-up from eMudhra mentions something about wrapping/unwrapping ceremony failing.
Any sufficiently advanced stupidity is indistinguishable from malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.
But the probability to receive one number or the other are the same.
smaller than 384 means 384 numbers (including 0) divided by the amount of possible numbers (see above) imho
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.
If I'm going to ask you or force you to share your password with me, there's no reason I'd ask you to set the password to 4. We might as well agree that the password would be D#!(s9fj0jalk!4af095SF42 , and it's much more likely our collaboration will continue working for years.
"Never attribute to malice that which is adequately explained by stupidity"
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
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.).
> Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
> 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...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
are you sure that this is not opening to more attack vector ?????
If it has been so weak already, it can't be weaker.
Flashing the devices require direct UART/USB access which may involve soldering, if it even exists. This leak is gold for those because these devices will never get an updated CRL.
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.