eMudhra: private keys with just 8 bits of security instead of 384

Eight private keys of eMudhra intermediate certificates, meant to provide 384 bits of security under the P-384 elliptic curve standard, turned out to be integers smaller than 256. The security margin that should make a key like that impossible to guess was reduced to a single byte: at most 256 values to try. Here's what happened on October 17, how browsers reacted, and what's still unconfirmed.

The notary of the internet

When you open your bank's website and the connection shows as secure (HTTPS), someone is vouching that the site is really what it claims to be, and that the password you type arrives encrypted. That someone is a certificate authority: it issues digital certificates that Chrome, Firefox, Safari and other browsers trust by default, because that authority is included in their «root programs» — the list of notaries trusted out of the box. eMudhra is one of India's major certificate authorities, and six of its intermediate certificates are trusted by the root programs of Chrome, Mozilla, Microsoft and Apple; two more, used for code signing, are trusted by Microsoft.

The stamp of a notary like that should be, literally, impossible to guess: under today's standard (the P-384 elliptic curve), we're talking about a private key randomly chosen from a number with 384 binary digits of possibility.

October 17

On October 17, 2026, a researcher reported to Mozilla (the report, forwarded by the Chrome Root Program, arrived at 20:06 UTC) that the private keys of eight eMudhra intermediate certificates — six for TLS, two for code signing — were not random 384-bit numbers at all. All eight were integers smaller than 256. In practice, a key meant to carry 384 bits of freedom was reduced to a single byte: at most 256 possible values to try, a brute-force search that on common hardware ends in a handful of attempts.

Those keys had been generated on April 30, 2025, and stayed in eMudhra's systems in that state until the report of October 17, 2026, before anyone noticed. It's still not clear why: eMudhra has pointed to the key-generation process in its hardware security module as the area under review, but the exact root cause has not been established.

The attack scenario: fraudulent certificates and interception

With only 256 possible values, recovering one of those private keys doesn't take a nation-state effort — it's a search that ends in a handful of tries. Whoever holds one of those keys can sign a certificate that browsers will accept as genuine for any domain — including your bank's — and use it to intercept the encrypted traffic of anyone connected, for instance, to a public wi-fi network. It's the textbook fraudulent-certificate scenario. Nothing in the public record so far shows documented abuse: the risk was real, but as far as is known it stayed theoretical.

The reaction

Mozilla received the report on October 17 at 20:06 UTC, forwarded by the Chrome Root Program, and independently derived the keys on its own by 21:48 UTC — under two hours later. It then revoked the keys in Firefox (via OneCRL) at 22:59 UTC, less than three hours after the report. Chrome corroborated the finding and updated its CRLSet with the six web-traffic keys at 22:46 UTC that same day. Apple corroborated the finding at 21:05 UTC and requested additional attestations from eMudhra. eMudhra revoked all eight affected certificates the next morning, October 18. Microsoft, according to the researcher who reported the case, still hadn't responded as of October 18. No documented abuse of these keys appears in the public record to date. Mozilla and Chrome, the browsers most people actually use, closed the hole on their end in hours, not days; for Apple, only corroboration and a request for additional attestations are confirmed.

Not DigiNotar, but a warning sign nonetheless

In 2011, another certificate authority, the Dutch DigiNotar, lost browsers' trust and shut down within months. This isn't the same problem: that was a breach resulting in fraudulent certificates, this is a badly generated key. But the consequence a certificate authority faces when trust cracks is the same one the whole system depends on: once browsers stop trusting you, your job as internet notary is over. On October 22, a formal request was opened on Mozilla Bugzilla to remove eMudhra's root certificates from browsers' built-in CA bundles (bug 2084865): it isn't a distrust decision yet, but it shows how much weight the incident carries on the compliance side of root program requirements.

The technical conclusion is simple: a key with only 8 bits of real security, against the 384 bits claimed under the P-384 standard, protects nothing, regardless of which standard it claims to meet. For a certificate authority, the gap between claimed and verifiable security is the only number that counts when trust has to be demonstrated, not assumed.

Sources

• Mozilla Bugzilla — Bug 2083449 — eMudhra: Private key compromise of Intermediate Certificates (primary source).
• Mozilla Bugzilla — Bug 2084865 — Remove eMudhra root certificates from in-tree CA bundles (open request, not a distrust decision).