upvote
I'm not so sure. If you wanted to be deliberate, you'd choose a plausible value that you could control.

No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.

reply
But that would be obviously intentional. Much more plausible deniability with 0x4.
reply
Why are many of them, suspicious?
reply
The probability of getting a 0 is the same for every digit. However, in my opinion, the probability of getting a number that starts with two zeros is 1/10 * 1/10, and the probability of getting a number that starts with the same two digits is 10 * 1/10 * 1/10.

But the probability to receive one number or the other are the same.

reply
By random chance you probably wouldn't get that many zeros. Of course, one could say it's just as random as any other string, but..
reply
Not a mathematician, but I'm sure the probability of them all being below 384 is going to be in the order of 0.000000001% if not less :)
reply
Sure, if they were actually sampling 384 bits. Sounds like they sampled a lot less than that; maybe someone though "384 bits" meant "in the range [0, 383]" or whatever.
reply
10 times the amount of digits is the possible number space.

smaller than 384 means 384 numbers (including 0) divided by the amount of possible numbers (see above) imho

reply
It's a 384-bit curve, so between 0 and 2^384 which has about 115 decimal digits.
reply
Makes no sense.

If it was deliberate, one would use keys that only the person abusing it has. Not keys everyone can guess if they get a hint.

reply
Deliberate deniability - if you leak a real key, it's pretty obvious you leaked a real key.

Here, you didn't leak anything, you just fucked up.

reply
Why would it be?
reply
Do I honestly need to enumerate what you can do if you have the keys for a CA?
reply
Yeah, but if you are the one issuing the CA's private key, you already, by definition, have the keys to that CA. You don't need to make stupid keys in that scenario
reply
In case it wasn't obvious. The NSA and many other organisation would find this extremely useful.
reply
But it doesn't make sense. Sure they'd find it extremely useful to have the key, but it doesn't need to be a weak key for it to be useful. If anything, it makes it less useful to them.

If I'm going to ask you or force you to share your password with me, there's no reason I'd ask you to set the password to 4. We might as well agree that the password would be D#!(s9fj0jalk!4af095SF42 , and it's much more likely our collaboration will continue working for years.

"Never attribute to malice that which is adequately explained by stupidity"

reply
A weak key means use is unattributable.
reply
A secret strong key is also unattributable.
reply
Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.
reply
As far as I know, to become a CA, with the requirements and ceremonies involved, this type of mistake must never happen. Assuming malice instead of ignorance is reasonable here. The entire premise of a CA, is trust.
reply
There are a lot of CAs that are essentially grandfathered into root programs (and there’s no “one” root program, every OS and verifier gets to choose their own inclusion policies). They might need to jump through hoops to stay in any given program, but being there in the first place is not a strong indicator of quality.
reply
> The entire premise of a CA, is trust.

No need for trustworthiness, then. /s

reply
I would be shocked if this was anything other than a bug. A CA already has the power to issue MITM certificates, so what reason would a CA have to deliberately generate bad keys?

In all likelihood it is code that reads 1 byte from /dev/random, or reads 32 bytes but writes it into a 1 byte array, or something to that effect.

reply