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 21 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 19 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 38 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.