Hacker News Reader

Comment by saidnooneever | Hacker News Reader

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

View on HN

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"

An elliptic curveball even

My guess is that someone was instructed to generate "random bytes" and just did 'char secret = rand()' or something similar.

Yup. I think they literally think a 256-bit key is just a random number between 1 and 255.

Looking at the pattern I would actually suspect a numberpad over top row of the keyboard. That explains how the responsible party got 1-5-6 without exhausting their delicate digits.

Why would they even do this? A standard random number generator is probably less work

More than that, they claim the key was in an HSM, so they likely could not look at it.

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

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.

Which means there was no way to know they were improperly generated, besides trying to actually bruteforce them, which you wouldn't do because it's usually pointless.

I wonder if the industry will adopt some sort of check mechanism to indicate the entropy in the key for these sealed keys?

entropy and length might help but it sounds more like duedilligence would be needed. u can have all the solutions in the world. if u dont know how to use them, they are just more problems

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

Doesn't even seem to be all that random within that range. For example all digits within each number go left to right on a keyboard.

I think it's worse than that. I think whoever did this genuinely thought that a "256-bit security key" meant a random number between 1 and 256.

That was a blasting key generation ceremony.

Chosen by fair dice roll

That could be wining numbers for a lottery

Reply on news.ycombinator.com