It was "multiple human errors". But yeah no matter what, in any case or exceptional circumstances, this thing was not supposed to be screwed up.

On Mozilla’s tracker, eMudhra said the keys were created on 30 April 2025 in a key generation ceremony, a recorded procedure in which keys are produced inside hardware security modules (HSMs), tamper-resistant devices built to hold keys. The keys were meant to be moved to data centres in the United States and Europe for customers needing data stored in those regions. To move them, the company added a step to ‘wrap’ each key, or encrypt it for transfer, and ‘unwrap’ it at the other end. eMudhra said a flaw in the software script created a second, weaker set of keys during this step, and because the two sets had similar names, staff used the weaker ones by mistake. It said human errors occurred at multiple steps.

source:

What's the eMudhra security scare that has rattled the internet?

https://theprint.in/tech/whats-the-emudhra-security-scare-th...

▲

wolvoleo 2 hours ago | parent [-]

These "wrapping" keys were not "weaker". They were completely unfit for purpose. They have not explained why they used a 3-bit key for this purpose.

If they go to the trouble of wrapping them, use real keys. Or don't do it.

Also, it's a big "human error" to not notice this for a year and a half.

▲

silisili 20 minutes ago | parent | next [-]

I have to imagine that the 3 bit numbers were slots/indexes on the HSM, and rather than actually retrieving the key(or maybe it did), the slot number got used as the key. I can't otherwise imagine how they'd generate such low number keys...

▲

patch_cable an hour ago | parent | prev | next [-]

Having worked around these types of devices and their interfaces, I doubt they intended to create weak keys.

It is more likely they had a script which placed a parameter in the wrong field, due to something like using positional arguments. Or they misread the documentation for some interface.

Still incompetence. And I would love to see my theory confirmed or refuted.

	▲	oofbey 17 minutes ago \| parent [-]
		I hear you in terms of how these kinds of mistakes typically happen. But why did the script ever produce two sets of keys? The initial root cause was somebody picked the weak key not the strong key. But what was the reason for ever producing a weak key in the first place? They say the script produced two outputs - what on earth for??

▲

cogman10 an hour ago | parent | prev | next [-]

Yeah. I can't think of any development process where you wouldn't simply use a production grade key in development. In fact, that's exactly what we do in development with snake oil keys.

Generating a key with "4" was probably done as a joke, but also is insane to have ever lived outside some devs computer.

▲

rockdoe 37 minutes ago | parent | prev | next [-]

I don't think it's implied the wrapping keys were the weak ones. More like, the script that ran the wrapping still had the fast "debug" generation of a pair of keys to test the wrapper on enabled, for example.

▲

telebub an hour ago | parent | prev [-]

Unwrapped extraction is the kind of thing security by checkbox covers and process review might catch so it is never clear in a case like this that some party with the capability to influence the process didn't want keys intentionally weak to emulate unwrap.. Then someone else may have introduced the swap of keys that would never have been seen with keys that would (be forever) in a public scrutiny DB.