OTC VOTE: EVP_PKEY private/public key components

[Billy Brumley]

>> > The private key is a random or pseudo-random 256-bit integer.
>> > How do you propose to "validate" that?
>>
>> For ECDSA it's not a a random or pseudo-random 256-bit integer: it's a
>> random or pseudo-random integer `k`, with `1 <= k < n`, not all
>> 256-bit integers fit into this definition for a 256-bit prime `n`
>> (where `n` is the order of the generator point for the curve.
>> Validating the private key guarantees that the input private scalar is
>> within the correct range.
>
>
> The key generator is responsible for that, not the signer.

Maybe in your use case. But not everyone's.

>> >  I was not "abusing the API" as you put it, merely pointing out that the public key is not a required item for performing ECDSA signature generation.  This is a mathematical fact of life that you are going to have to learn to live with.

Everybody knows the math fact already. There's no sense in repeating
it. Even other software projects like BoringSSL, MbedTLS, etc know
this, yet still compute the public key when it's missing. I don't have
a strong opinion about that either way, but pointing out some middle
school math and claiming that's the end of the argument is not
constructive.

And IMO you are indeed "abusing the API" or we wouldn't be having this
conversation. You have a niche use case, and rolling your own key
format, and now changes are biting you, so you're speaking up. (And
quite rudely, I might add. Please remember that many OpenSSL
contributors, including myself and Nicola, are volunteering their
time.)

> There exists no private key value which will cause the EVP_sign operation to enter an endless loop.
> The operation will always return a result, which may not be useful if it is impossible to generate the corresponding public key.

I honestly don't understand. You're wrong, and the PoC shows it. (The
infinite loop is my PoC btw, so if you want to discuss it please feel
free to do so with me directly.)

BBB