Top
Best
New

Posted by hkc 14 hours ago

Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds(scotthelme.co.uk)
791 points | 386 commentspage 3
positive-spite 13 hours ago|
That's some criminal negligence right there.

8 bits is crazytalk!

joshuat 13 hours ago||
“4”

hey chatgbg what is a “private key”

Agentlien 12 hours ago|||
As someone from Gothenburg, Sweden (often referred to as gbg) I shall answer:

A private key is a tiny number you don't need to share publicly because it is easy enough to guess.

Hamuko 13 hours ago|||
Maybe they were counting on the fact that usually the right answer to “I’m thinking of a number between 1 and 10” is “7”.
bombcar 11 hours ago|||
Isn't 4 simply 2 bits?

Silly 2-bit outfit.

Maybe it's 3 bits.

patrickthebold 11 hours ago||
I think the way that the bits are counted is based on the pool from which the number was randomly drawn. So it's possible they had 256 bits of entropy but got really unlucky.
thesz 8 hours ago||
Their other keys are also in 0..255 range. This is definitely not "really unlucky."

I guess they used (x `mod` 256) instead of (x `mod` (2^256)).

mnx 11 hours ago||
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
andix 5 hours ago||
I'm wondering how many other private keys might be cropped to 32, 64 or 128 bit and much weaker than we think. Seems like nobody tested it yet. Otherwise the 8 bit would've been found within minutes.
cududa 5 hours ago||
It’d be absurd to believe nobody tested these, and that no individuals involved in relevant standards bodies were aware of this weakness.
andix 5 hours ago|||
Those 8 bit certs were out for over a year, in the public. So nobody tested them. At least no independent security researcher.
pixl97 5 hours ago||||
We live in an absurd universe, the absurd should be expected.
floydnoel 5 hours ago|||
"absolutely no way that there is a $100 bill on the sidewalk- if there were, somebody would have picked it up already"
Scott_Helme_ 5 hours ago||
If you've got the compute power, it's easy enough to have a go at it!
__MatrixMan__ 5 hours ago||
Is it legal? I thought the DMCA protects flimsy security of this kind by making it illegal to check if its flimsy.
andix 5 hours ago|||
No idea what the DMCA says. It doesn't apply in most parts of the world, and also not where I live. So it's for sure legal somewhere.
Scott_Helme_ 5 hours ago|||
I'm not sure what laws apply to you where you live so you'd have to check, but you could also do this on pen and paper if that helps :)
andix 5 hours ago|||
What I've heard about the DMCA, they will even throw you in jail if you crack the calculation in your head. Without telling anyone or writing it down. ;)
Qision 13 hours ago||
It feels like they chose the private keys by hand.
PalmPilotProMax 13 hours ago||
Artisanal cryptography. Hand-picked private keys salted with organically sourced nonces.
tclancy 13 hours ago|||
Brooklyn-based. Guy in overalls and a waxed mustache hands out the bits.
bigfishrunning 9 hours ago||
Don't forget the leather apron, it's a messy job
donandon 13 hours ago||||
Made with love
account42 12 hours ago|||
Sharing is caring after all.
muvlon 12 hours ago|||
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.

account42 12 hours ago|||
All the numbers also have digits going from left to right on a keyboard. I think the manual "random" input theory is plausible.
muvlon 11 hours ago|||
Oh wow, that is even more damning. Only 146 out of the possible 256 keys have this property. You only have about a 1% chance to get that 8 times in a row (A little more than 1% if sampling with replacement and a little less if sampling without. You'd expect them to at least not use the exact same key twice but at this point???).
Avamander 12 hours ago|||
Some error code being used? FIPS mode gone wrong?
gquere 10 hours ago|||
There's a beginning of an explanation in the mozilla bugrepor thttps://bugzilla.mozilla.org/show_bug.cgi?id=2083449
mminer237 9 hours ago||
Thanks. The relevant quote:

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

benmmurphy 9 hours ago||
`a flaw in the code resulted in the second pair of keys being created onboard which were weaker`

that sounds like the HSM is capable of generating keys in a range that is smaller than [1..group_order). such a feature makes no sense at all. or is this some kind of weird thing where people want to generate weak keys for 'testing' and HSM vendors have added such a strange feature. its actually satisfying to see someone get burned by this because such a feature should never exist and this is the reason why. if the HSM can generate keys in a smaller range (especially some arbitrary small range) then you are putting a lot of trust in the operators of the HSM. hopefully there are good audit logs and people actually check the audit logs every time keys are generated to make sure the keys being generated aren't from a special range.

walrus01 12 hours ago|||
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.
Fabricio20 12 hours ago||
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/

dlcarrier 18 hours ago||
I thought CAs automatically filtered out really low keys. There's a great Suckerpinch video (https://youtu.be/M1si1y5lvkk) about trying to purposely make the least secure HTTPS page possible, and Tom initially tried to choose a laughably-low number as the key, but the CA automatically rejected it.
zkmon 5 hours ago||
>> "These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025".

the Audit part is scary. The same audit process might have cleared many other stuff.

https://www.einpresswire.com/article/951151580/emudhra-state...

icedchai 5 hours ago|
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.
closetheloopdev 6 hours ago||
After my shock and anger subside, I can think more clearly now. I see many have mentioned using this to perform MITM on the IoT devices.

On the other hand, can we not utilize that to also protect the IoT devices? Can we not create a MITM proxy on our own network that proxies all of our IoT devices's traffic and then forwards them to the trusted HTTPS, MQTTS, ... endpoints upstream? Since the proxy already revokes these bad certificates, the upstream traffic should be protected. We should be able to revoke any other bad certs in the the future as well.

Scott_Helme_ 6 hours ago|
Yeah, this would work.
closetheloopdev 6 hours ago||
Thank you! Working on the proxy now ...
childintime 10 hours ago||
1. So there was no certification of the certifiers?

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.

greengreengrass 9 hours ago||
> promise security and.. make a profit

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

missinglugnut 7 hours ago||
The company had a valuation of about $500million USD (converted from INR) before the incident. Now it's likely worthless, because of an incident that could have been prevented by hiring one competent person.

Moral hazard describes situations where an entity is incentivized to take undue risk. With an upside of saving a single Indian endineers salary and a downside of destroying the entire company, it's safe to say the market wasn't incentivizing this. They were just stupid.

badgersnake 9 hours ago||
Like a web-of-trust model?
TazeTSchnitzel 13 hours ago||
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
swiftcoder 12 hours ago||
Count yourself lucky - compared to Claude's prose, this is fairly readable.
jadamson 13 hours ago|||
It reads fine to me. If it is AI, I'd like to know which one so I can use it too.
stratos123 12 hours ago|||
It reads okay to me too, yet Pangram says it's mixed - the "What a private key actually is" section is AI, so is 'Why "it cannot be contained"' and some others.
TazeTSchnitzel 13 hours ago||||
I think it's a hybrid text. The section about how elliptic curve keys work is particularly aggravating. Unfortunately it's also the only section that gave me new information.
karel-3d 12 hours ago|||
It has parts that are human written and parts that are generated. I couldn't tell at first, but now seeing it in Pangram, it's kind of clear.
Scott_Helme_ 9 hours ago||
It was all written by me and then I had final pass/tweak with Claude.
queenkjuul 6 hours ago||
So parts were generated... Unless you're saying Claude just went "lgtm, ship it"
Scott_Helme_ 6 hours ago||
Fair enough, call it a mix if you like. I'm happy to stand behind every claim in my post, and if something's wrong, tell me and I'll fix it.
marsven_422 13 hours ago||
[dead]
kyleomalley 10 hours ago|
Question: what about the other trusted roots? Has anyone tested them?

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

sam1714 4 hours ago|
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.

More comments...