Comment by saidnooneever
11 hours ago
I BET this is an error code. they wanted to generate some key via something and it errors and put error code 4 as key and since encryption is dumb and people are people, no one looked at the key material.
edit: The reported private scalars were 4, 56, 66, 115, 155, 156, 230, 237 across the eight certificates so its unlikely i will win my bet :'D
The first 6 keys are literally someone typing them in lazily on a keyboard. You can almost see their fingers barely moving across the top numeric row as they generate them.
You can see the thought at 230 of "Ok, that was dumb, gotta move my fingers on the numpad slightly this time to throw them a curveball"
More than that, they claim the key was in an HSM, so they likely could not look at it.
Someone answering “questions for emudhra” also say the keys were intended to be exported to US and EU data centers. I don’t know if that would have precluded inspection (hopefully it’s encrypted some way, but why not have the destination HSM generate the CSR?)
Edit: I see the below paragraph is quoted extensively below. I hadn’t seen those comments yet. Oh well
Source: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
Content:
We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
The RSA issuers went through a different path as per our assessment of the code and are therefore not impacted. Some additional context - these issuers created were meant for export to our US and European data centers to solve data sovereignty issues for some of our customers (but never ended up operationally in production except for one).
Wrapping/unwrapping means the HSM would generate the private key and then encrypt it with a key only known to the other HSMs. Those other HSMs would then decrypt the key on import. The private key should still have been impossible to examine outside the HSMs.
i wonder how many keys they thought it had. reading them byte by byte xD 'this HSM is excellent we can litterally put _all_ our keys in it!'
and thx for the context. i rly wonder now how it went down lol
These read like Lotto numbers and I bet someone in the underworld has made bank with them.
Random number 0-255
Hey that's a byte of entropy! And one of the rare cases where choosing a larger value might offer you better "protection" against serialized brute force attacks
That was a blasting key generation ceremony.
Chosen by fair dice roll
That could be wining numbers for a lottery