Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds
scotthelme.co.uk101 points by hkc 2 hours ago
101 points by hkc 2 hours ago
In retrospect, having 100 trusted certificate authorities might have been excessive.
In retrospect, not having a tiny competency check may have been an oversight.
Two more things to note about impact assessment: Flatpak uses the selected runtime's baked-in trust store (I think), so any apps may be susceptible even if you update the system package. Containers also don't inherit the host's trust store and use the one from the base image.
Related: https://news.ycombinator.com/item?id=50166579
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
Of COURSE it's easy to crack, 4 isn't even prime!
In their defense, they were probably targeting the Mersenne prime 2^2 - 1 and just made a typo.
All the numbers were under 384. Surely they couldn't have ...
I wouldn't be surprised if we learn in the near future, that this was deliberate.
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.
Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.
Why would it be?
Do I honestly need to enumerate what you can do if you have the keys for a CA?
I will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
That's some criminal negligence right there.
8 bits is crazytalk!
“4”
hey chatgbg what is a “private key”
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”.
It feels like they chose the private keys by hand.
Artisanal cryptography. Hand-picked private keys salted with organically sourced nonces.
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
It reads fine to me. If it is AI, I'd like to know which one so I can use it too.
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.
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.
> and no TLS certificates chaining to these CAs ever showed up in CT
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
This is not a good write-up. Yesterday's discussion did contain better data, less self-Promotion and actually asked why it happened, instead of just saying "number small".
eMudhra explanation : https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
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.
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?
Even just a human glancing at the private key should do it.
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.
hey, at least it was easy to remember...