How do you even make a private key that is equal to 4?

The First Teaching: A key is just a number

A private key is not a magic artefact. It is a number. On the P-384 curve it is a number with about 115 digits, and the public key is that number multiplied by a fixed starting point called G.

Any number in range is mathematically valid. The curve does not care whether you picked it with a quantum dice or typed it with one finger. 4 is in range. 4 works. The signatures are perfectly good signatures.

So how does a 4 get into a vault built to hold a 115-digit secret? The usual gremlins:

• The leftover test value. Someone loads a placeholder to “just test the plumbing”, and the placeholder never leaves.

• The broken random number generator. The dice are loaded, and every key comes out small, or the same.

• The HSM, import or ceremony mistake. A key is created outside the box, imported, wrapped, unwrapped, or simply picked by the wrong label.

Then nobody checks. Software validates that the key is on the curve. It does not ask whether the key is suspiciously small. And anyone who suspects it can do what a child does with a jar of sweets: count. 1·G, 2·G, 3·G, 4·G. Match found.

The Master calls this “brute force”. The novice calls it “Tuesday”.

Teaching: The mathematics never lies. It simply never asks.

The Second Teaching: The ceremony with an approved deviation

Two keys in one box.
Their names differ by a breath.
The wrong one is crowned.

On 30 April 2025, eMudhra held a key ceremony on Utimaco HSMs. It produced 24 keys across series A, B and C, in RSA-4096 and P-384, for DV, OV, EV and code signing.

What follows is eMudhra’s own preliminary account (Bugzilla comment 11). Its own status page says it has “not yet confirmed the exact root cause”.

• The proper, strong ECC keys were generated on the HSM as normal.

• Because the keys were meant for export to the EU and US, staff added an “approved deviation” to test wrap and unwrap.

• “A flaw in the code” of the ceremony script created a second key pair. That one was weak.

• The two key pairs had similar labels. The weak ones went into the certificate signing requests, which the root signed and which also went to Sectigo, which cross-signed them on 14 May 2025.

• eMudhra blames “human errors in multiple steps”.

The result: eight intermediate CAs, all ECDSA P-384, six for TLS and two for code signing, whose private keys were each less than 256. All zeroes, except the last byte. The key for EM OV TLS CA - G3C was 4 (published by researcher Flüpke and matched to the certificate by BleepingComputer).

Critics on the bug point out that genuine HSM key generation does not produce numbers under 256. Either test material was fed in, or the key was made outside the HSM. Both readings contradict the CPS. Eight keys all under 256 is a pattern, not bad luck.

Two keys walk into an HSM. The one with the better label wins.

Teaching: Ceremonies fail at the label, not at the maths.

The Third Teaching: The bell that rang in June

The bell rang in June.
The monks fixed it by striking
harder with the crack.

In June 2025 the system raised its hand. Bug 1970728: eMudhra’s revocation lists for exactly these six TLS intermediates had invalid signatures.

eMudhra now admits it had signed those lists with the original strong keys, which did not match the certificates. The fix was to re-sign the lists with the weak keys. The incident was filed as a “manual CRL key configuration” error and closed on 6 June 2025. Mozilla notes the archive shows the lists failing from 23 May, earlier than the cause eMudhra gave.

The alarm went off. They answered it by using the bad key.

Teaching: When the system says the key does not match, the question is “which key is real?”, not “how do I make it match?”

The Fourth Teaching: Counting, at scale

On 17 October 2026 at 16:00 UTC, a researcher known as Wayne was “playing with some new toys”. At 16:27 a scan of a CCADB test corpus found the break. At 18:05 he emailed Apple, Chrome, Microsoft, Mozilla and eMudhra with proof of key control.

Mozilla received the report via Chrome at 20:06 UTC. Working “without any knowledge of the method”, it recovered the keys itself at 21:48, 1 hour 42 minutes later. The file was named oh_dear.zip. Mozilla’s Dennis Jackson says local AI agents recovered the keys “on their first attempt” from a CTF-style prompt.

Then the gates closed:

• 17 Oct, 22:46 UTC: Chrome’s CRLSet revokes the six TLS intermediates.

• 17 Oct, 22:59 UTC: Firefox OneCRL is complete.

• 18 Oct: eMudhra revokes all eight as caCompromise, about 15.5 hours after the report.

• 19 Oct: Apple ships protections, and Sectigo revokes its cross-signs.

• 20 Oct: Mozilla announces emergency distrust of emSign ECC Root CA - G3, and Chrome follows.

• 21 Oct: the Talos advisory, a Go CVE, and patches for certifi, pip, rustls and others.

The collateral: about 30,800 unexpired certificates chained to that root, 99.9% of them belonging to Internet2/InCommon. eMudhra says the weak intermediates issued no end-entity certificates. Talos reports no exploitation observed as of 21 October. The keys had been trivially recoverable for about 18 months, so nobody can promise more than that.

Teaching: Counting to four is now a threat model. Run the dumb checks before someone’s agent does.

The Fifth Teaching: Two independent audit cycles

eMudhra says the hierarchy passed “two independent audit cycles”.

The novice asked the Master: “How did two audits miss a key of 4?”

The Master said: “The auditors asked whether the ceremony had a script. It had a script. They asked whether the deviation was approved. It was approved. They asked whether the HSM was certified. It was certified.”

“And did anyone ask whether the key was 4?”

“That,” said the Master, pouring tea, “was not on the checklist.”

Audits check procedures and paperwork. They do not check whether a public key is a tiny multiple of G. Nobody runs d·G for d < 2^16 against their own CSRs. It takes seconds, and it would have saved a root.

Final Teaching: The audit certified the ritual. The key was still 4.

Sources (facts as compiled in the research pack, 22 Oct 2026): Mozilla Bugzilla 2083449 (the incident, including eMudhra’s preliminary account in comment 11), Mozilla Bugzilla 1970728 (the June 2025 CRL signatures), the eMudhra status page (Updates 1-3), the Cisco Talos advisory (21 Oct 2026), and BleepingComputer (20 Oct 2026). The root-cause report is still pending, and eMudhra’s account is preliminary.