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

hkc 870 points 413 comments October 21, 2026
scotthelme.co.uk · View on Hacker News

Discussion Highlights (20 comments)

alwa

Bugzilla bug in question: https://.mozilla.org/showbug.cgi?id=2083449

pwfisher

Test your browser and update your system's certificates: https://emudhra.we-have-a-problem.com/

unsupp0rted

Never attribute to malice what can be explained by ignorance? In this case I wonder if this was an intentional wide open doorway to fraud

dlcarrier

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.

positive-spite

That's some criminal negligence right there. 8 bits is crazytalk!

bombcar

Of COURSE it's easy to crack, 4 isn't even prime!

WalterGR

Related: https://news.ycombinator.com/item?id=50166579 “eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments

Qision

It feels like they chose the private keys by hand.

naabozaurus

hey, at least it was easy to remember...

jlmorton

In retrospect, having 100 trusted certificate authorities might have been excessive.

maeln

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.

siwatanejo

https://xkcd.com/221/

TazeTSchnitzel

Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?

gagan2020

"Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh." This statement is more discerning than anything else. It raises question about why this certificates exists in first place if not deployed since 2025. Is it deliberate attempt to do compromising of system? In recent times, Indian Government is becoming quite rogue and don't follow the said procedures. So, it might be related to that as well.

hypfer

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

tclancy

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.

sscaryterry

I wouldn't be surprised if we learn in the near future, that this was deliberate.

dist-epoch

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

supernes

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.

dbcooper

All the numbers were under 384. Surely they couldn't have ...

Semantic search powered by Rivestack pgvector
10,209 stories · 96,238 chunks indexed