Nimendra's Notes 🪴

eMudhra's Private Key = 4 Incident (2026)

6 min read

cybersecurity casestudies cryptography

The core failure

In October 2026, eight intermediate Certificate Authorities operated by eMudhra were found to have extremely weak private keys, including 4, 56, and 115.

The cryptographic algorithm was secure, but the keys generated and selected for use were dangerously predictable.

How does HTTPS trust work?

When you visit https://example.com, your browser must verify that the website is genuinely who it claims to be.

This relies on PKI and digital certificates.

A Certificate Authority (CA) is a trusted organization that digitally signs certificates to confirm identities.

flowchart TD
    A["🔐 Root CA<br/>(Trusted by Browser)"]
    B["🏛️ Intermediate CA"]
    C["📄 Website Certificate"]
    D["🌐 Browser Verifies the Chain"]

    A -->|Signs| B
    B -->|Signs| C
    C -->|Presented to Browser| D

    style A fill:#dbeafe,stroke:#2563eb,color:#1e40af
    style B fill:#e0f2fe,stroke:#0284c7,color:#075985
    style C fill:#dcfce7,stroke:#16a34a,color:#166534
    style D fill:#f3e8ff,stroke:#9333ea,color:#6b21a8
  • Root CA: The top-level trust anchor already trusted by the browser.
  • Intermediate CA: Receives authority from a root CA to issue certificates.
  • Website certificate: Connects a website’s identity to its public key.

Each CA has a key pair:

  • Private key: Secret, used for digital signatures.
  • Public key: Shared openly, used to verify signatures.

Important: If an intermediate CA’s private key becomes known, attackers can potentially create fraudulent certificates that appear to have been issued by a trusted authority.

First Principles — Why is a private key of 4 dangerous?

eMudhra used P-384 Elliptic Curve Cryptography (ECC).

The fundamental idea is simple:

Where:

  • d = Secret private key (a number).
  • G = Publicly known point on the elliptic curve.
  • Q = Public key derived from the private key.

The security depends on this asymmetry:

  • Calculating Q from d is easy.
  • Recovering d from Q should be computationally infeasible.

What makes a strong private key?

A secure P-384 private key is randomly selected from an enormous range containing approximately () possibilities.

Think of it like a PIN, but instead of a few digits, there are around 116 decimal digits worth of possible values.

However, ECC mathematically accepts small numbers too. For example, d = 4 is technically valid.

The problem is predictability, not mathematical validity.

If the key is known to be between 1 and 255, an attacker needs to check only 255 candidates.

Public key Q is available in the certificate.

Try d = 1 → calculate 1 × G → No match
Try d = 2 → calculate 2 × G → No match
Try d = 3 → calculate 3 × G → No match
Try d = 4 → calculate 4 × G → MATCH!

Private key recovered: 4

This is a Brute Force Attack, but on such a tiny search space that it takes negligible computing power.

The eight recovered private keys were: 4, 56, 66, 115, 155, 156, 230, 237 All fit within a single byte (8 bits).

A 384-bit cryptographic algorithm does not guarantee 384-bit security if the private key comes from a predictable, tiny set of numbers.

What Actually Happened?

According to eMudhra’s preliminary investigation:

  1. April 30, 2025: During a formal Key Generation Ceremony, strong ECC keys were generated using Hardware Security Modules (HSMs).
  2. Procedure modification: A key wrap/unwrap operation was introduced to support moving cryptographic keys between environments. Wrapping means securely packaging a key for transport or storage.
  3. Script flaw: The modified procedure accidentally created a second set of extremely weak keys.
  4. Wrong key selected: Because both sets had similar labels, operators mistakenly selected the weak keys.
  5. Certificates signed: Certificate Signing Requests (CSRs) containing those weak public keys were approved by eMudhra’s root CA. Some were also cross-signed by Sectigo.
  6. Undetected: The certificates remained in the trust ecosystem for approximately 18 months.

Why didn’t the HSM prevent this?

An HSM protects cryptographic operations and key material, but it cannot guarantee that surrounding scripts, key selection, and operational procedures are correct.

The exact code-level flaw responsible for the tiny values had not been confirmed as of October 23, 2026. A specific truncation or random-number-generator failure should not be assumed without evidence.

Discovery, Impact and Response

DateEvent
Apr 30, 2025Weak intermediate CA keys created
Jun 2025Related certificate revocation list (CRL) signing-key mismatch identified, but the underlying weakness remained undetected
Oct 17, 2026Researcher reported control of eight private keys; browser vendors began blocking them
Oct 18, 2026eMudhra revoked all eight intermediate certificates
Oct 20–21, 2026Public disclosure and broader distrust of the affected ECC root

What could attackers do?

With a recovered intermediate CA private key, an attacker could potentially:

  • Sign fraudulent HTTPS certificates for domains they do not own.
  • Impersonate websites if they can intercept network connections.
  • Undermine certificate-based trust in affected systems.
  • Abuse compromised code-signing authority keys for fraudulent software signatures.

Six affected intermediates were for TLS certificates, and two were for code signing.

Actual known impact

  • eMudhra stated that none of the eight intermediates had issued end-entity certificates.
  • No exploitation before disclosure had been confirmed.
  • Browser vendors blocked the affected intermediates and moved to distrust the related ECC root.
  • The root’s private key itself was not reported as compromised.

This was a severe potential trust compromise, not proof that all HTTPS traffic had been intercepted.

Lessons

  1. Cryptography is only as strong as its key generation. Secure algorithms cannot rescue predictable secrets.
  2. Validate keys, not just certificates. Confirm the exact key used matches the intended securely generated key; test for obvious weak-key patterns.
  3. Hardware security is not end-to-end security. HSMs cannot replace secure scripts, human verification, or independent reviews.
  4. Treat unusual cryptographic failures as warning signals. The earlier CRL signing-key mismatch deserved deeper investigation.
  5. Trust requires continuous verification. Audits, revocation mechanisms, and operational controls are essential even after certificates have been issued.

Final takeaway

The mathematics did not fail; the surrounding engineering process did.

A private key such as 4 was sufficient to produce a mathematically valid ECC public key, but was trivial for anyone to discover.

This incident demonstrates why Entropy, Key Management, Certificate Authorities, and operational security are just as important as choosing a strong cryptographic algorithm.

Graph View