Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-23 Thread Matt Caswell
This vote is now closed. Viktor's vote was a little unclear but I interpreted it as a -1 in recording the votes. accepted: yes (for: 5, against: 4, abstained: 1, not voted: 1) Matt On 03/11/2020 12:11, Matt Caswell wrote: > Background to the vote: > > The OTC meeting today discussed the

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Nicola Tuveri
I will only answer what I see as new points in your last email, to avoid repeating ourselves. Validity of a serialized key: - ASN.1 validity says little about the validity of the key, as ASN.1 cannot enforce limits on the private scalar range - validity as a serialized EC key requires that in

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Richard Levitte
This is what I read: - the key in p256_invalid.pem is invalid in other ways than merely the lack of the public key in the file. (the public key is *not* lacking in run-time in this example, since d2i_ECPrivateKey() autogenerates it, which happens before it's checked or used) - you

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Nicola Tuveri
The issue with that key is that the secret scalar `k` is equal to `n` (where `n` is the order of the generator point `G`), while for EC keys the validity range is `1 <= k < n`. If the scalar `k` is equal to `n`, it means that the associated pubkey is `k*G` = `n*G` = `0*G mod n` = `P_infinity`.

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Nicola Tuveri
It exists in master but not in 1.1.1 or previous: the incomplete EVP_PKEY object of #12612 in previous versions would have failed validation, where its correctness as a math entity and as a programming object is tested. That is why I am baffled by the use of "regression" to describe this issue,

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Richard Levitte
Er, Nicola, I'm unsure how that endless loop has anything to do with the presence or the absence of a public key, as it happens in ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at all. Your check does say that the key you have there is invalid, but that would rather be because

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Richard Levitte
On Wed, 11 Nov 2020 23:34:53 +0100, Nicola Tuveri wrote: > > By design the consistency checks and validation checks are omitted > unless these functions are called, and there is no > EVP_PKEY_private_check. Just a small point, this is in master: $ grep private_check include/openssl/evp.h

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Richard Levitte
On Sun, 15 Nov 2020 22:36:54 +0100, Kurt Roeckx wrote: > > On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote: > > > > The proposal discussed was that while relaxing the conceptual model, > > most of the existing implementations would still require both. The EC > > implementation would

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread 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

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-16 Thread Dick Franks
On Thu, 12 Nov 2020 at 10:33, Nicola Tuveri wrote: > > >8 > > > 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

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-15 Thread Kurt Roeckx
On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote: > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-12 Thread Nicola Tuveri
On Thu, Nov 12, 2020 at 11:42 AM Dick Franks wrote: > > On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote: >> >> >> In particular in 1.1.1, the key created as depicted in #12612 that >> triggered this discussion (Matt posted a useful reproducer among the >> first comments), is indeed capable of

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-12 Thread Dick Franks
On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote: > > In particular in 1.1.1, the key created as depicted in #12612 that > triggered this discussion (Matt posted a useful reproducer among the > first comments), is indeed capable of signing in the used pattern, but > the pattern is conveniently

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread Nicola Tuveri
Usually the labs provide assurances on the key generation and the other cryptographic operations, including validation, but have special provisions to avoid providing assurances on key serialization and deserialization. This seems particularly true in the context of the FIPS validation for

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread SHANE LONTIS
Key assurance really depends on what you are doing, so I don't think this is quite true. For example if you generate a key using a valid algorithm (that is validated by a lab), then there is already an assurance that the key is valid without needing to run EVP_PKEY_check(). There are many

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread Nicola Tuveri
In light of recently working more closely to `EVP_PKEY_check()` I would add to the discussion on this vote that it is not entirely true that we were not enforcing the keypair assumption and that the current strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t. some uses that work in

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-09 Thread Tim Hudson
r 3, 2020 1:11 PM > > To: openssl-project@openssl.org > > Subject: OTC VOTE: EVP_PKEY private/public key components > > > > Background to the vote: > > > > The OTC meeting today discussed the problems raised by issue #12612. In > > summary the problem is th

RE: OTC VOTE: EVP_PKEY private/public key components

2020-11-09 Thread Dr. Matthias St. Pierre
0 > -Original Message- > From: openssl-project On Behalf Of Matt > Caswell > Sent: Tuesday, November 3, 2020 1:11 PM > To: openssl-project@openssl.org > Subject: OTC VOTE: EVP_PKEY private/public key components > > Background to the vote: > > T

OTC VOTE: EVP_PKEY private/public key components

2020-11-03 Thread Matt Caswell
Background to the vote: The OTC meeting today discussed the problems raised by issue #12612. In summary the problem is that there has been a long standing, widespread and documented assumption that an EVP_PKEY with a private key will always also have the public key component. In spite of this it