4 ms·
Nothing much to see here. ECC private keys are just random numbers. The reported issue is that, if the random number happens to be encodable in fewer bytes tha
by agl 12y ago
Nothing much to see here.
ECC private keys are just random numbers. The reported issue is that, if the random number happens to be encodable in fewer bytes than expected, the spec says that it should be padded with leading zeros, but OpenSSL doesn't do that.
For example, if you generate 32-bit random numbers, you expect a few to be only three bytes long (and even a few to be two or one). The difference is whether you write 0x123456 or 0x00123456. There's no security impact. At worst, an OpenSSL-generated ECC key might be rejected by other code.
Since OpenSSL has been doing this forever (based on the report) in practice this means that we should update the spec :)
- userbinator 12y agoAt worst, an OpenSSL-generated ECC key might be rejected by other code. Private keys are almost certainly kept private so the amount of software that handles them is relatively limited (I'd bet that the majority of the time it's OpenSSL), but how about public ECC keys? As I understand it, they could be embedded in certificates and signed, in which case a signature verifier that uses the "correct" encoding might fail. However, AFAIK almost all SSL certificates out there use RSA and ECC is pretty rare, so this problem has little impact.
- agl 12y agoECC public keys use a different encoding (X9.62). There's nothing in the report that suggests a problem there.