First, as many have pointed out, eMudhra as a trusted certificate authority has issued eight high-level certificates with a key length of onle 3-8 bits, when they should be 384 bits long. And yes, the smallest key was '4'.
But the other point is tha xkcd predicted using 4 as a random number, decades ago. It was supposed to be a joke.
There is a massive security incident this week where an Indian certificate authority used 4 as the private key they used to sign encrypted internet traffic with.
Knowing their secret key lets anyone forge certificates that they can use to snoop on or modify internet traffic.
All 8 of their private keys were under 255, so could be trivially guessed. These certificates were accepted by all major browsers and operating systems, as well as many programming languages and tools.
I think it technically was not "brute forcing" (since it wasn't found by searching the entire key space), but specifically someone tried generating CA cert private keys from numbers 0-255, and surprisingly found a few.
We don't know whether anyone tried it before April 2025, because that's when the vulnerable certificates were issued. If someone did try it before then, they would not find any certificates (as expected) and probably wouldn't even talk to anyone about it.
It feels like the kind if thing that someone, somewhere would have a script running constantly testing for private keys with low values. That it went 18 months without being found is a miracle!
I think there's a good chance people will be looking for this now so will get caught a lot quicker next time.
I think there’s a good chance people will be looking for this now so will get caught a lot quicker next time.
That's pretty much guaranteed from now on, yes.
It feels like the kind if thing that someone, somewhere would have a script running constantly testing for private keys with low values. That it went 18 months without being found is a miracle!
It's not the kind of thing you'd expect to need to guard against, or even really think of. It should not happen. It sounds like someone was kind of just fooling around with making private keys and stumbled upon it.
I guess now someone needs to try seeding some of the most popular PRNGs with 0-255 and seeing whether any keys come up in the first few hundred numbers.
It’s just as arbitrary as any other number. You can pick at random, but starting with a dictionary attack of easy, non-random keys would probably be a better start.
I remember playing a game of dvd-deal or no deal, where you would pick random number from one to twenty and see if you won money. The people I was playing with were mad because I just started guessing 1, 2, 3, 4…
I told them statistically it was just as likely to be those numbers as anything else.
Security by obscurity is what it’s called in the industry, and yeah it’s not a good way to do it. Automation and scripts would make it trivial to guess.
It's kinda like locking your door by putting a wedge in the crack. Probably, no one is going to try to open your door anyways, and probably, even if they did no one is going to take 5 seconds to examine the door and figure it out
But if someone does, it's laughably easy to figure it out
I think their analogy is still good. Just add "...and your door opens onto Times Square."
That doesn't quite get the full scope, but it does imply the danger pretty well. Plus, if you add in "...Times Square of robots, and the robots are all thieves, and your most expensive possession is visibly sitting right inside, and..." it starts to get pretty unwieldy.
No it absolutely does, the method they used to generate private keys ended up having just 8 shannons of entropy which led to the discovery we are discussing
Nit: That that key doesn’t technically encrypt traffic, if I understand correctly. It’s used to verify the identify of a website. So someone with this private key can’t directly read internet traffic. They can set up a man-in-the-middle attack, but they’d also have to compromise DNS to pull it off.
It’s a little more complex than that. But if you want to encrypt, and you do want your site traffic encrypted, you use site certificate to give the client browser proof that you are who you say you are. You do this by establishing a chain of trust: “I got this proof that I am who I say I am from this major trusted certificate authority” you trust them and they trust me, so we’re all good. You’ve probably seen the warning that a site isn’t secure, and that’s because they let their certificate of trust expire.
This low entropy key means it’s trivial for me to fake that I have that major authority’s trust. The browser needs to be updated to no longer trust that authority. Until it does I can easily fake being anyone and say that compromised site vouches for me. I don’t even need to be a man in the middle, I just need to set up a way that your browser sends you to my fake server instead of the real one. Lots of ways to do that.
I just dont understand why they would do this? Putting so shitty key is like they wanted to make it as insecure as possible. Even if the ones responsible were criminally stupid, they still should have understood that this is like leaving the whole thing unlocked.
And for such critical thing. Imagine if this wasnt discovered like this but instead by some competent malicious actor that had resources to coordinate some large scale attack and kept it hidden until just the right moment when they can strike at everything.
I also dont understand how little outrage there even is about this, we were really close to huge catastrophe. Or maybe i have misunderstood the severity of what happened.
They are saying there were mistakes made with their key generation scripts:
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)
I'm not so sure. Because shortly after the above quote they answered this to the next question:
Is there any reason which may explain why the A and A-1 ECDSA keys appear to be unaffected by similar issues?
The A and A-1 series were created in Entrust HSMs and were meant for deployment only in India.
And previously in Comment 10 they said about the bad keys
These ICAs were generated from the same key ceremony on Apr 30, 2025. The G3B and G3C ICAs were created for European and US operations respectively but they were not put into production except #2 in the list below but no end entity certificates were issued from these. The Code Signing issuers were not put into production also did not issue any certificates.
That's why I think somehow the intended place of use made a difference in their process. But it could be you're right and they still mean HSM export, because the keys need to go to the region of use, and aren't transported physically in the HSM.
Interesting question! Google spit this out and it makes sense:
The primary reason these specific keys/issuers were created was to solve data sovereignty and data residency requirements for customers in those regions.
Many European and US corporate clients operate under strict legal frameworks (like GDPR in Europe or various federal compliance standards in the US) that legally dictate where cryptographic infrastructure can live, where data can be decrypted, and who can possess the root or intermediate private keys.
Generating separate regional keys is a compliance mechanism to guarantee that a customer's data or handshake traffic stays within their jurisdiction.
Google is wrong. There is no security benefit to using an SSL certificate signer in your jurisdiction because a hacked or malicious certificate authority in another jurisdiction can man-in-the-middle you or your customers just as effectively.
Certificate authorities do not decrypt data or even transfer it on behalf of customers.
It's hard to properly describe how big a fuckup this is. All I will say is that all the coverage I've seen is underselling the potential for harm. There's nothing you can do except update your shit, pray that everyone in the upstream supply chain of every service you use has updated their shit, and take comfort in the fact that there are no proven wild exploits out there (yet).
Well, even if there's no update for your shit, it's still possible to go into the certificate store your browser/OS/whatever uses and delete the compromised certificates.
Not much you can do about everyone else not updating their shit though.
Yeah. The burden is high, though, and it's outside even most tech-savvy admins' scope of knowledge.
I mean, I could not tell you off the top of my head how many certificate stores exist on my system and what uses each of them. Is curl safe? Is dnf safe? apt-get? zypper? pip? npm? homebrew? flatpak? Do any of my umpteen Flatpak apps have vulnerable library versions baked in? Do Electron apps bundle their own certificate stores? What about that has its own built-in autoupdater (less of a problem on Linux than Mac or Windows, but still)?
64 replies
TL;DR Because a Certificate Authority used 4 as a private key in an intermediate certificate.
We live in a simulation https://xkcd.com/221/
Well ..... this has taken me down am SSL cryptographic rabbit hole.
There are two parts to this answer.
First, as many have pointed out, eMudhra as a trusted certificate authority has issued eight high-level certificates with a key length of onle 3-8 bits, when they should be 384 bits long. And yes, the smallest key was '4'.
But the other point is tha xkcd predicted using 4 as a random number, decades ago. It was supposed to be a joke.
https://xkcd.com/221/
xkcd also happened to release a comic about a "vulnerability in the number 3" the same day the eMudhra news broke.
Check the alt text on that one :-)
5 is objectively more secure than 4, unless 4 was perfectly random, of course.
That's not "happened to"; read the title text if you want to remove all reasonable doubt that it's a reference to it.
I think they italcized that word because it was sardonic.
Oh my god, I thought that was a recent meme someone made because of this debacle, didn't know it was an OG xkcd...
supposed to ...
There is a massive security incident this week where an Indian certificate authority used 4 as the private key they used to sign encrypted internet traffic with.
Knowing their secret key lets anyone forge certificates that they can use to snoop on or modify internet traffic.
All 8 of their private keys were under 255, so could be trivially guessed. These certificates were accepted by all major browsers and operating systems, as well as many programming languages and tools.
But, since nobody would expect an organization like that to have a one digit key, wouldn't that make it extremely hard to guess?
Half kidding here.
Not if you're brute forcing it.
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100
I think it technically was not "brute forcing" (since it wasn't found by searching the entire key space), but specifically someone tried generating CA cert private keys from numbers 0-255, and surprisingly found a few.
So why did it take so long for someone to try it?
Kind of like how you don't expect to walk up to an atm, press 1234, and hope for a million dollars to spit out.
We don't know whether anyone tried it before April 2025, because that's when the vulnerable certificates were issued. If someone did try it before then, they would not find any certificates (as expected) and probably wouldn't even talk to anyone about it.
It feels like the kind if thing that someone, somewhere would have a script running constantly testing for private keys with low values. That it went 18 months without being found is a miracle!
I think there's a good chance people will be looking for this now so will get caught a lot quicker next time.
That's pretty much guaranteed from now on, yes.
It's not the kind of thing you'd expect to need to guard against, or even really think of. It should not happen. It sounds like someone was kind of just fooling around with making private keys and stumbled upon it.
I guess now someone needs to try seeding some of the most popular PRNGs with 0-255 and seeing whether any keys come up in the first few hundred numbers.
"Time to brute force this key, I guess I will go get some lun.... What do you mean it's already done? Who uses 4????"
Ain’t no way I’m starting from 0 if the standard key is 256-bit
It’s just as arbitrary as any other number. You can pick at random, but starting with a dictionary attack of easy, non-random keys would probably be a better start.
I remember playing a game of dvd-deal or no deal, where you would pick random number from one to twenty and see if you won money. The people I was playing with were mad because I just started guessing 1, 2, 3, 4…
I told them statistically it was just as likely to be those numbers as anything else.
Security by obscurity is what it’s called in the industry, and yeah it’s not a good way to do it. Automation and scripts would make it trivial to guess.
It's kinda like locking your door by putting a wedge in the crack. Probably, no one is going to try to open your door anyways, and probably, even if they did no one is going to take 5 seconds to examine the door and figure it out
But if someone does, it's laughably easy to figure it out
Except this is internet and pretty much anybody on the planet could test the security of your doors.
I like the analogy but I think it doesn't really apply when it comes to devices that are connected to the internet.
I think their analogy is still good. Just add "...and your door opens onto Times Square."
That doesn't quite get the full scope, but it does imply the danger pretty well. Plus, if you add in "...Times Square of robots, and the robots are all thieves, and your most expensive possession is visibly sitting right inside, and..." it starts to get pretty unwieldy.
Well, someone did guess it so it's not that hard. The entropy was really low.
'Entropy' doesnt apply here
It does doesn't it?
The higher the number of bits, the more entropy in the system.
It's a pointlessly obscure way of saying there are more numbers
Its a measure of the randomness of numbers in the system, ie the definition of entropy.
People do use it to sound cool, but this use still fits its mathematic definition.
I know. Its still pointlessly obscure
No it absolutely does, the method they used to generate private keys ended up having just 8 shannons of entropy which led to the discovery we are discussing
Nit: That that key doesn’t technically encrypt traffic, if I understand correctly. It’s used to verify the identify of a website. So someone with this private key can’t directly read internet traffic. They can set up a man-in-the-middle attack, but they’d also have to compromise DNS to pull it off.
It’s a little more complex than that. But if you want to encrypt, and you do want your site traffic encrypted, you use site certificate to give the client browser proof that you are who you say you are. You do this by establishing a chain of trust: “I got this proof that I am who I say I am from this major trusted certificate authority” you trust them and they trust me, so we’re all good. You’ve probably seen the warning that a site isn’t secure, and that’s because they let their certificate of trust expire.
This low entropy key means it’s trivial for me to fake that I have that major authority’s trust. The browser needs to be updated to no longer trust that authority. Until it does I can easily fake being anyone and say that compromised site vouches for me. I don’t even need to be a man in the middle, I just need to set up a way that your browser sends you to my fake server instead of the real one. Lots of ways to do that.
Yes, I think you’re correct
I just dont understand why they would do this? Putting so shitty key is like they wanted to make it as insecure as possible. Even if the ones responsible were criminally stupid, they still should have understood that this is like leaving the whole thing unlocked.
And for such critical thing. Imagine if this wasnt discovered like this but instead by some competent malicious actor that had resources to coordinate some large scale attack and kept it hidden until just the right moment when they can strike at everything.
I also dont understand how little outrage there even is about this, we were really close to huge catastrophe. Or maybe i have misunderstood the severity of what happened.
They are saying there were mistakes made with their key generation scripts:
Source: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
Personally I'm still a little confused why it makes any difference that the keys were intended for export to their European and US operations
By "export" I think they mean export off of the hardware security module (HSM). Not export geographically.
I'm not so sure. Because shortly after the above quote they answered this to the next question:
And previously in Comment 10 they said about the bad keys
That's why I think somehow the intended place of use made a difference in their process. But it could be you're right and they still mean HSM export, because the keys need to go to the region of use, and aren't transported physically in the HSM.
Interesting question! Google spit this out and it makes sense:
The primary reason these specific keys/issuers were created was to solve data sovereignty and data residency requirements for customers in those regions.
Many European and US corporate clients operate under strict legal frameworks (like GDPR in Europe or various federal compliance standards in the US) that legally dictate where cryptographic infrastructure can live, where data can be decrypted, and who can possess the root or intermediate private keys.
Generating separate regional keys is a compliance mechanism to guarantee that a customer's data or handshake traffic stays within their jurisdiction.
Google is wrong. There is no security benefit to using an SSL certificate signer in your jurisdiction because a hacked or malicious certificate authority in another jurisdiction can man-in-the-middle you or your customers just as effectively.
Certificate authorities do not decrypt data or even transfer it on behalf of customers.
It's about compliance, not security.
Because it was revealed that an actual TLS certificate used the number 4 as a private key.
Not just a tls certificate, A root CA certificate trusted by pretty much everything
I'm glad I use good ol' 12345!
Amazing. I have the same combination on my luggage.
I'm surrounded by Assholes!
because 42 would have been too obvious.
You may find that answr from another community helpful: https://feddit.online/comment/10016475
That was a really good answer actually
Aw, thanks
An organization trusted with the security of potentially billions of people essentially used the password "4" among other bad choices.
You can read the technical explanation here: https://emudhra.we-have-a-problem.com/
https://arstechnica.com/security/2026/10/the-internet-goes-on-high-alert-after-discovery-of-8-compromised-tls-certs/
It's hard to properly describe how big a fuckup this is. All I will say is that all the coverage I've seen is underselling the potential for harm. There's nothing you can do except update your shit, pray that everyone in the upstream supply chain of every service you use has updated their shit, and take comfort in the fact that there are no proven wild exploits out there (yet).
Well, even if there's no update for your shit, it's still possible to go into the certificate store your browser/OS/whatever uses and delete the compromised certificates.
Not much you can do about everyone else not updating their shit though.
Yeah. The burden is high, though, and it's outside even most tech-savvy admins' scope of knowledge.
I mean, I could not tell you off the top of my head how many certificate stores exist on my system and what uses each of them. Is curl safe? Is dnf safe? apt-get? zypper? pip? npm? homebrew? flatpak? Do any of my umpteen Flatpak apps have vulnerable library versions baked in? Do Electron apps bundle their own certificate stores? What about that has its own built-in autoupdater (less of a problem on Linux than Mac or Windows, but still)?
I tried to read the comments, but I couldn't get in:
In my defense, the comm is No Stupid Questions, not No Stupid Comments.
"Lemmeme" tho. 'twas RIGHT there.