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.
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
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.
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.
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.
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.
But that would be obviously intentional. Much more plausible deniability with 0x4.
Why are many of them, suspicious?
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.
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..
4 replies →
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.
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.
Why would it be?
Do I honestly need to enumerate what you can do if you have the keys for a CA?
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
4 replies →
Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.
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.
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.
> The entire premise of a CA, is trust.
No need for trustworthiness, then. /s
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.