Re: OTC VOTE: EVP_PKEY private/public key components

[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 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 turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
> 
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
> 
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
> 
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
> 
> 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 behaviour between 1.1.1 and 3.0.
> 
> The vote text is as follows:
> 
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
> 
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[  ]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [-1]
> 

Re: OTC VOTE: EVP_PKEY private/public key components

[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 addition to be
valid ASN.1, other criteria are satisfied:
  - (this is assuming a named curve, with explicit parameters things
get more involved, as we need to validate those before looking at
private and public components)
  - private scalar is in the prescribed range for the curve
  - if optional public component is present, the public key encoding
matches the SECG standard in one of the supported compression formats
  - if optional public component is present, the public key point
belongs to the curve
  - if optional public component is present, the public key point
belongs to the prime subgroup of the curve (this collapses into the
previous point only if the cofactor for this curve is 1)
  - if optional public component is present, the public key point matches `k*G`


I confirm what you saw in your experiments, the validity checks (if
invoked!) catch these corner cases (I did similar experiments when
preparing the EC part of #13359).


The fact that you had to alter `ec_key_simple_check_key()` to skip the
public component validation, which is necessary also in 1.1.1 and
earlier, is the reason why I raised this side discussion on key
validation, as disproving the "lack of enforcement" argument: but I
posted this on the public openssl-project list only after verifying we
did not have gaping security holes.


Nicola

On Mon, Nov 16, 2020 at 8:51 PM Richard Levitte  wrote:
>
> 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 confirmed that the public key isn't really relevant for this
>   problem, apart from triggering a check error that's really emanating
>   from some other invalid data.
>
> This does not, however, demonstrate what happens when the EVP_PKEY
> holds an EC_KEY that lacks a public key, because in run-time, it in
> fact does *not* lack a public key.  So while that's an interesting
> discussion, it doesn't really demonstrate your concerns about this
> vote.
>
> BTW, regarding checking, I did a bit of an experiment; I removed the
> autogeneration of the public key from d2i_ECPrivateKey(), and relaxed
> ec_key_simple_check_key() so it only checks eckey->pub_key if it's
> actually present...  and of course removeed a few eckey->pub_key NULL
> checks along the way.  EVP_PKEY_check still fails, but now with the
> detailed error "wrong order", which sounds perfectly reasonable
> considering your description, so it looks to me like the invalidity
> of the key can be caught either way.
>
> From a contents point of view, p256_invalid.pem is actually perfectly
> valid, or you would have gotten ASN1 errors when trying to load it.
>
> Cheers,
> Richard
>
> P.S.  I'd like to pause the debate at this point...  it looks like
> we're getting back into locked positions, and I'm not keen on
> continuing under those conditions.
>
> On Mon, 16 Nov 2020 19:06:51 +0100,
> Nicola Tuveri wrote:
> >
> > 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`.
> > The pubkey generation in the `d2i_` routines is correctly being
> > triggered because the PEM file I generated only includes the secret
> > scalar: if we did not catch the point at infinity validating the
> > public component we would reach the private component validity checks
> > and we would trigger the private scalar range check.
> >
> > The infinite loop happens not because of the public component (that as
> > we know is not touched during signature generation) but because the
> > secret scalar is effectively congruent to `0 mod n` in the computation
> > to generate the `s` value of the signature.
> >
> > I would not classify this as a bug, but as a programmer error: the
> > user is using an invalid key (this has nothing to do with the "keypair
> > assumption", literally `k` is a value out of range according to the
> > relevant spec).
> > Input key material should be validated: if not at each run (for
> > performance reason), once after it has been serialized to disk and
> > protected with proper measures to ensure the validated key material is
> > not tampered with (or leaked).
> >
> >
> > If we consider this a bug, or a potential DoS attack vector, we would
> > likely fix it by running validation of the `EVP_PKEY` object on load
> > (and with some caching 

Re: OTC VOTE: EVP_PKEY private/public key components

[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 confirmed that the public key isn't really relevant for this
  problem, apart from triggering a check error that's really emanating
  from some other invalid data.

This does not, however, demonstrate what happens when the EVP_PKEY
holds an EC_KEY that lacks a public key, because in run-time, it in
fact does *not* lack a public key.  So while that's an interesting
discussion, it doesn't really demonstrate your concerns about this
vote.

BTW, regarding checking, I did a bit of an experiment; I removed the
autogeneration of the public key from d2i_ECPrivateKey(), and relaxed
ec_key_simple_check_key() so it only checks eckey->pub_key if it's
actually present...  and of course removeed a few eckey->pub_key NULL
checks along the way.  EVP_PKEY_check still fails, but now with the
detailed error "wrong order", which sounds perfectly reasonable
considering your description, so it looks to me like the invalidity
of the key can be caught either way.

From a contents point of view, p256_invalid.pem is actually perfectly
valid, or you would have gotten ASN1 errors when trying to load it.

Cheers,
Richard

P.S.  I'd like to pause the debate at this point...  it looks like
we're getting back into locked positions, and I'm not keen on
continuing under those conditions.

On Mon, 16 Nov 2020 19:06:51 +0100,
Nicola Tuveri wrote:
> 
> 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`.
> The pubkey generation in the `d2i_` routines is correctly being
> triggered because the PEM file I generated only includes the secret
> scalar: if we did not catch the point at infinity validating the
> public component we would reach the private component validity checks
> and we would trigger the private scalar range check.
> 
> The infinite loop happens not because of the public component (that as
> we know is not touched during signature generation) but because the
> secret scalar is effectively congruent to `0 mod n` in the computation
> to generate the `s` value of the signature.
> 
> I would not classify this as a bug, but as a programmer error: the
> user is using an invalid key (this has nothing to do with the "keypair
> assumption", literally `k` is a value out of range according to the
> relevant spec).
> Input key material should be validated: if not at each run (for
> performance reason), once after it has been serialized to disk and
> protected with proper measures to ensure the validated key material is
> not tampered with (or leaked).
> 
> 
> If we consider this a bug, or a potential DoS attack vector, we would
> likely fix it by running validation of the `EVP_PKEY` object on load
> (and with some caching mechanism to validate keys created manually via
> `EC_KEY` objects): this would once again reveal that the use pattern
> in #12612 was invalid to begin with, as the validity checks were
> enforcing the "keypair assumption" in 1.1.1 and previous versions.
> 
> 
> Nicola
> 
> On Mon, Nov 16, 2020 at 7:44 PM Richard Levitte  wrote:
> >
> > 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 from that private key and group, it seems that
> > d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed
> > infinity as I understand it.  You can see that for yourself with a
> > breakpoint at d2i_ECPrivateKey(), step down to about line 1042
> > (current OpenSSL_1_1_1-stable, btw), and simply look:
> >
> > (gdb) p *ret->pub_key
> > $16 = {meth = 0x77f0dc00 , curve_name = 415, X = 
> > 0x556450f0,
> >   Y = 0x55645090, Z = 0x556450b0, Z_is_one = 0}
> > (gdb) p *ret->pub_key->Z
> > $17 = {d = 0x55641170, top = 0, dmax = 4, neg = 0, flags = 1}
> > (gdb) p *ret->pub_key->X
> > $18 = {d = 0x55641ec0, top = 4, dmax = 4, neg = 0, flags = 1}
> > (gdb) p *ret->pub_key->Y
> > $19 = {d = 0x55641e40, top = 4, dmax = 4, neg = 0, flags = 1}
> >
> > (ret->pub_key->Z->top == 0, that's a bignum zero)
> >
> > That still has no impact on the infinite loop as far as I can see, but
> > that may be an indication that something else is wrong with that
> > private key.
> >
> > It's also possible that if there are conditions that may cause an
> > infinite loop, that is a bug in itself 

Re: OTC VOTE: EVP_PKEY private/public key components

[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`.
The pubkey generation in the `d2i_` routines is correctly being
triggered because the PEM file I generated only includes the secret
scalar: if we did not catch the point at infinity validating the
public component we would reach the private component validity checks
and we would trigger the private scalar range check.

The infinite loop happens not because of the public component (that as
we know is not touched during signature generation) but because the
secret scalar is effectively congruent to `0 mod n` in the computation
to generate the `s` value of the signature.

I would not classify this as a bug, but as a programmer error: the
user is using an invalid key (this has nothing to do with the "keypair
assumption", literally `k` is a value out of range according to the
relevant spec).
Input key material should be validated: if not at each run (for
performance reason), once after it has been serialized to disk and
protected with proper measures to ensure the validated key material is
not tampered with (or leaked).


If we consider this a bug, or a potential DoS attack vector, we would
likely fix it by running validation of the `EVP_PKEY` object on load
(and with some caching mechanism to validate keys created manually via
`EC_KEY` objects): this would once again reveal that the use pattern
in #12612 was invalid to begin with, as the validity checks were
enforcing the "keypair assumption" in 1.1.1 and previous versions.


Nicola

On Mon, Nov 16, 2020 at 7:44 PM Richard Levitte  wrote:
>
> 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 from that private key and group, it seems that
> d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed
> infinity as I understand it.  You can see that for yourself with a
> breakpoint at d2i_ECPrivateKey(), step down to about line 1042
> (current OpenSSL_1_1_1-stable, btw), and simply look:
>
> (gdb) p *ret->pub_key
> $16 = {meth = 0x77f0dc00 , curve_name = 415, X = 0x556450f0,
>   Y = 0x55645090, Z = 0x556450b0, Z_is_one = 0}
> (gdb) p *ret->pub_key->Z
> $17 = {d = 0x55641170, top = 0, dmax = 4, neg = 0, flags = 1}
> (gdb) p *ret->pub_key->X
> $18 = {d = 0x55641ec0, top = 4, dmax = 4, neg = 0, flags = 1}
> (gdb) p *ret->pub_key->Y
> $19 = {d = 0x55641e40, top = 4, dmax = 4, neg = 0, flags = 1}
>
> (ret->pub_key->Z->top == 0, that's a bignum zero)
>
> That still has no impact on the infinite loop as far as I can see, but
> that may be an indication that something else is wrong with that
> private key.
>
> It's also possible that if there are conditions that may cause an
> infinite loop, that is a bug in itself that needs a fix.
>
> I believe this loop is due for a raised issue, unless there already is
> one.
> (if there isn't, I wonder why)
>
> Cheers,
> Richard
>
> On Thu, 12 Nov 2020 11:33:13 +0100,
> Nicola Tuveri wrote:
> >
> > > Nonsense.  Each iteration involves a new PRN, which by definition you 
> > > cannot predict.
> >
> > ~~~sh
> > ; which openssl; openssl version
> > /usr/bin/openssl
> > OpenSSL 1.1.1f  31 Mar 2020
> > ; cat > /tmp/p256_invalid.pem
> > -BEGIN PRIVATE KEY-
> > MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/AP//
> > vOb6racXnoTzucrC/GMlUQ==
> > -END PRIVATE KEY-
> > ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem
> > Key is invalid
> > Detailed error: point at infinity
> > Private-Key: (256 bit)
> > priv:
> > ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:
> > ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63:
> > 25:51
> > pub:
> > 00
> > ASN1 OID: prime256v1
> > NIST CURVE: P-256
> > ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32
> > ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash
> > -out /tmp/sig.der
> > # here is the infinite loop
> > ~~~
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/

Re: OTC VOTE: EVP_PKEY private/public key components

[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,
and the reason why I commented on the "lack of enforcement" argument.

Cheers,

Nicola

On Mon, Nov 16, 2020, 18:53 Richard Levitte  wrote:

> 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
> int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx);
>
> Cheers,
> Richard
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
>

Re: OTC VOTE: EVP_PKEY private/public key components

[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 from that private key and group, it seems that
d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed
infinity as I understand it.  You can see that for yourself with a
breakpoint at d2i_ECPrivateKey(), step down to about line 1042
(current OpenSSL_1_1_1-stable, btw), and simply look:

(gdb) p *ret->pub_key 
$16 = {meth = 0x77f0dc00 , curve_name = 415, X = 0x556450f0, 
  Y = 0x55645090, Z = 0x556450b0, Z_is_one = 0}
(gdb) p *ret->pub_key->Z
$17 = {d = 0x55641170, top = 0, dmax = 4, neg = 0, flags = 1}
(gdb) p *ret->pub_key->X
$18 = {d = 0x55641ec0, top = 4, dmax = 4, neg = 0, flags = 1}
(gdb) p *ret->pub_key->Y
$19 = {d = 0x55641e40, top = 4, dmax = 4, neg = 0, flags = 1}

(ret->pub_key->Z->top == 0, that's a bignum zero)

That still has no impact on the infinite loop as far as I can see, but
that may be an indication that something else is wrong with that
private key.

It's also possible that if there are conditions that may cause an
infinite loop, that is a bug in itself that needs a fix.

I believe this loop is due for a raised issue, unless there already is
one.
(if there isn't, I wonder why)

Cheers,
Richard

On Thu, 12 Nov 2020 11:33:13 +0100,
Nicola Tuveri wrote:
> 
> > Nonsense.  Each iteration involves a new PRN, which by definition you 
> > cannot predict.
> 
> ~~~sh
> ; which openssl; openssl version
> /usr/bin/openssl
> OpenSSL 1.1.1f  31 Mar 2020
> ; cat > /tmp/p256_invalid.pem
> -BEGIN PRIVATE KEY-
> MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/AP//
> vOb6racXnoTzucrC/GMlUQ==
> -END PRIVATE KEY-
> ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem
> Key is invalid
> Detailed error: point at infinity
> Private-Key: (256 bit)
> priv:
> ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:
> ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63:
> 25:51
> pub:
> 00
> ASN1 OID: prime256v1
> NIST CURVE: P-256
> ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32
> ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash
> -out /tmp/sig.der
> # here is the infinite loop
> ~~~

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OTC VOTE: EVP_PKEY private/public key components

[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 
int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx);

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OTC VOTE: EVP_PKEY private/public key components

[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 be relaxed however. This essentially gives largely
> > compatible behaviour between 1.1.1 and 3.0.
> > 
> > The vote text is as follows:
> > 
> > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> > * relax the conceptual model to allow private keys to exist without public
> >   components;
> > * all implementations apart from EC require the public component to be
> > present;
> > * relax implementation for EC key management to allow private keys that
> > do not
> >   contain public keys and
> > * our decoders unconditionally generate the public key (where possible).
> > 
> > Proposed by Matt Caswell
> > Public: yes
> > opened: 2020-11-03
> > closed: 2020-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
> So I think being compatible with what 1.1.1 does is important.
> And what the text does is try to make rules for what 1.1.1 does,
> but as far as I understand it, it's not really describing what
> 1.1.1 does.
> 
> I think we should just fix the regressions. For fixing the
> regressions we don't need a vote.

The vote includes exactly the items needed to fix the regression.  In
reality, this is already mostly fixed, because all our new decoders
will reconstruct the public key exactly the same way the old backends
did, because they all call the exact same d2i_{TYPE}PrivateKey()
internally, which do the actual work.

The only actual work remaining to fix the regression is to relax the
EC keymgmt import function to accept receiving a private key without
the public key.  It doesn't actually need to regenerate a public key
either.  That will allow a construct similar to the one that was
reported in #12612.

In practical terms, that doesn't sound like very hard work.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 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

Re: OTC VOTE: EVP_PKEY private/public key components

[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 < 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.



>
> Sidenote: I don't know how the software in question does keygen, if it
> is happening outside of OpenSSL or not, but validating the key
> generation step is also crucial, because the random integer generation
> should have a uniform distribution over the whole range without any
> biases.
>

If you do not know how the keys are generated, it is obvious that you have
not read #12612



> >
> >  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.
> >
>
> I agree that performing an ECDSA signature generation does not require
> the public key, and that would be reason in favor of relaxing the
> assumption.
>

So why do you persist in arguing against it?


> I am not saying it is wrong to want to generate signatures only with
> the private key, I am saying that it does not fit well with the
> OpenSSL API design (and with most other cryptographic libraries, not
> just OpenSSL forks, that also have similar "keypair assumptions").
>

If OpenSSL API design conflicts with the well-understood requirements of EC
cryptography, then OpenSSL will need to change, because the mathematics
certainly is not going to change.



>
> A counter argument to yours is that ECDSA signature verification
> requires only the public component, and it is a mathematical fact of
> life that knowledge of the private component in this case implies
> knowledge of the public component.
>

So what?



> A user of a cryptographic library can therefore expect that an
> abstract key object embedding knowledge of the private key is capable
> of being used in operations requiring knowledge of the public
> component, including ECDSA signature verification.
>

If I know the private key, I have no need at all to verify a signature
using the public key.


> Computing the public component on demand only when such operation is
> requested is a sub-optimal design choice from both performance and
> security points of views, and robust cryptographic libraries have to
> deal with it.
>

Agree



> We can reach different compromises, relaxing the documented assumption
> as this vote proposes, and then offering API functions for the most
> generic use cases and specialized API functions for specific use cases
> like yours. I'm not arguing against doing that moving forward, I am
> arguing about categorizing the current strict behavior of EC keymgmt
> in 3.0 as a "breaking change" and considering the current use pattern
> of the reproducer in #12612 against 1.1.1 as "supported" in the
> current LTS release.
>

#12612 reports a change which breaks code that runs on every version from
1.0.1 to 3.0.0-alpha5.


>
> >>
> >> Omitting the `EVP_PKEY_check()` in the reproducer and the user
> >> application, would for example allow me to write a DoS attack: the
> >> secret scalar could easily be hand-picked to trigger an endless loop
> >> in the sign operation.
>

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.



> ~~~sh
> ; which openssl; openssl version
> /usr/bin/openssl
> OpenSSL 1.1.1f  31 Mar 2020
> ; cat > /tmp/p256_invalid.pem
> -BEGIN PRIVATE KEY-
> MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/AP//
> vOb6racXnoTzucrC/GMlUQ==
> -END PRIVATE KEY-
> ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem
> Key is invalid
> Detailed error: point at infinity
> Private-Key: (256 bit)
> priv:
> ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:
> ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63:
> 25:51
> pub:
> 00
> ASN1 OID: prime256v1
> NIST CURVE: P-256
> ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32
> ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash
> -out /tmp/sig.der
> # here is the infinite loop
> ~~~
>
>
ROFL!



--RWF

Re: OTC VOTE: EVP_PKEY private/public key components

[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 behaviour between 1.1.1 and 3.0.
> 
> The vote text is as follows:
> 
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
> 
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

So I think being compatible with what 1.1.1 does is important.
And what the text does is try to make rules for what 1.1.1 does,
but as far as I understand it, it's not really describing what
1.1.1 does.

I think we should just fix the regressions. For fixing the
regressions we don't need a vote. You can argue that that would
violate some rule or model that some people think we have, but
clearly we didn't have it.

So I'm voting -1.


Kurt

Re: OTC VOTE: EVP_PKEY private/public key components

[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 signing in the used pattern, but
>> the pattern is conveniently omitting the validation pass that should
>> be required in any serious use of the API.
>
>
> 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.

Sidenote: I don't know how the software in question does keygen, if it
is happening outside of OpenSSL or not, but validating the key
generation step is also crucial, because the random integer generation
should have a uniform distribution over the whole range without any
biases.

>>
>> `EVP_PKEY_check()`
>> (https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is
>> one of the many places in 1.1.1 where both the documentation and the
>> behavior assume that an `EVP_PKEY` object is a keypair.
>> Even in the version used by the user that posted the issue, running
>> `EVP_PKEY_check()` on the created key would have revealed that the
>> user was abusing the API.
>
>
>  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.
>

If the documentation of the API says that an `EVP_PKEY` must include a
full keypair, and the functions to validate a manually initialized
`EVP_PKEY` object enforce this, then I stand by my assessment that
writing software that intentionally initializes a non-compliant
`EVP_PKEY` object which would not pass validation functions of the API
(where the documented assumption is enforced) configures as an "API
abuse" from a programming point of view.

I agree that performing an ECDSA signature generation does not require
the public key, and that would be reason in favor of relaxing the
assumption.
I am not saying it is wrong to want to generate signatures only with
the private key, I am saying that it does not fit well with the
OpenSSL API design (and with most other cryptographic libraries, not
just OpenSSL forks, that also have similar "keypair assumptions").

A counter argument to yours is that ECDSA signature verification
requires only the public component, and it is a mathematical fact of
life that knowledge of the private component in this case implies
knowledge of the public component.
A user of a cryptographic library can therefore expect that an
abstract key object embedding knowledge of the private key is capable
of being used in operations requiring knowledge of the public
component, including ECDSA signature verification.
Computing the public component on demand only when such operation is
requested is a sub-optimal design choice from both performance and
security points of views, and robust cryptographic libraries have to
deal with it.

We can reach different compromises, relaxing the documented assumption
as this vote proposes, and then offering API functions for the most
generic use cases and specialized API functions for specific use cases
like yours. I'm not arguing against doing that moving forward, I am
arguing about categorizing the current strict behavior of EC keymgmt
in 3.0 as a "breaking change" and considering the current use pattern
of the reproducer in #12612 against 1.1.1 as "supported" in the
current LTS release.

>>
>> Omitting the `EVP_PKEY_check()` in the reproducer and the user
>> application, would for example allow me to write a DoS attack: the
>> secret scalar could easily be hand-picked to trigger an endless loop
>> in the sign operation.
>
>
> Nonsense.  Each iteration involves a new PRN, which by definition you cannot 
> predict.

~~~sh
; which openssl; openssl version
/usr/bin/openssl
OpenSSL 1.1.1f  31 Mar 2020
; cat > /tmp/p256_invalid.pem
-BEGIN PRIVATE KEY-
MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/AP//
vOb6racXnoTzucrC/GMlUQ==
-END PRIVATE KEY-
; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem
Key is invalid
Detailed error: point at infinity
Private-Key: (256 bit)
priv:
ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:
ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63:
25:51
pub:
00
ASN1 OID: prime256v1
NIST CURVE: P-256
; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32
; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash
-out /tmp/sig.der
# here is the infinite loop
~~~

--

Re: OTC VOTE: EVP_PKEY private/public key components

[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 omitting the validation pass that should
> be required in any serious use of the API.
>

The private key is a random or pseudo-random 256-bit integer.
How do you propose to "validate" that?



> `EVP_PKEY_check()`
> (https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is
> one of the many places in 1.1.1 where both the documentation and the
> behavior assume that an `EVP_PKEY` object is a keypair.
> Even in the version used by the user that posted the issue, running
> `EVP_PKEY_check()` on the created key would have revealed that the
> user was abusing the API.
>

 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.



> >8
>
> Omitting the `EVP_PKEY_check()` in the reproducer and the user
> application, would for example allow me to write a DoS attack: the
> secret scalar could easily be hand-picked to trigger an endless loop
> in the sign operation.
>

Nonsense.  Each iteration involves a new PRN, which by definition you
cannot predict.


--RWF

Re: OTC VOTE: EVP_PKEY private/public key components

[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
OpenSSL, where the encoders/decoders are outside the scope of the FIPS
module and of validation.

The issue that triggered this discussion is particularly an issue of
encoding/decoding: the user application uses a custom format, and that
is the reason why the `EVP_PKEY` object is built from an `EC_KEY`
object built from scratch.
The application has only these ways to validate if the created
`EVP_PKEY` object is valid from a programmer's perspective AND as a
cryptographic object:

- EVP_PKEY_check (check an EVP_PKEY keypair)
- EVP_PKEY_public_check (check an EVP_PKEY pubkey, or just the public
component of an EVP_PKEY keypair)
- EVP_PKEY_param_check (check an EVP_PKEY params object, or just the
params component of an EVP_PKEY keypair or pubkey)

By design the consistency checks and validation checks are omitted
unless these functions are called, and there is no
EVP_PKEY_private_check.

To me this proves that what was described as a "breaking change" in
3.0 with strict EC keymgmt, is instead a programmer error in the
application that abused the API with an incomplete initialization,
which would have been detected if the dedicated validation functions
were called appropriately.
Even if the security policies that apply to the users of that
application wouldn't require to validate the cryptographic properties
of the key every time they are loaded because of external processes
and assurances, the developers of the application would have
discovered they were abusing the API if they tried validating the
half-initialized objects even just in development builds, which in my
opinion debunks the "lack of enforcement" argument that partially
supported the discussion that led to this vote.



In light of this I would dare say that:

a) the current "strict" state of EC keymgmt in 3.0 does not represent
a "breaking change" w.r.t 1.1.1, as it only catches existing API
abuses that were catched in 1.1.1, if only the half-initialized
objects were validated
b) relaxing the "keypair assumption" for EVP_PKEY objects is entirely
a new feature


Neither of these points makes the vote "invalid", but they could
change some of the casted votes, and they would strengthen my -1 in a
-2 if it were an option.

--

Nicola


P.S. For the record, given that I expressed this mostly in the virtual
meetings rather than in the discussion thread in the mailing list,
while from these emails it might seem like I hate with fiery rage the
idea of relaxing the keypair assumption, this is not really the case.
My main concern is changing this deeply rooted and pervasive
assumption in the timeframe of the 3.0 release, and with (IMO)
insufficient test coverage to make sure that we can transition to a
more relaxed model without introducing defects that could translate
into security risks.

On Wed, Nov 11, 2020 at 11:58 PM SHANE LONTIS  wrote:
>
> 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 operations that don't need EVP_PKEY_check, but they may need a 
> sub check such as
> EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or 
> EVP_PKEY_pairwise_check (or some combination of those).
> Keys (and certs) that are received from another entity should be validated 
> unless there is some other mechanism for establishing that the key is trusted.
>
>
> On 12 Nov 2020, at 12:14 am, Nicola Tuveri  wrote:
>
> 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 1.1.1.
>
> 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 omitting the validation pass that should
> be required in any serious use of the API.
>
> `EVP_PKEY_check()`
> (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$
>  ) is
> one of the many places in 1.1.1 where both the documentation and the
> behavior assume that an `EVP_PKEY` object is a keypair.
> Even in the version used by the user that posted the issue, running
> `EVP_PKEY_check()` on the created key would have revealed 

Re: OTC VOTE: EVP_PKEY private/public key components

[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 operations that don't need EVP_PKEY_check, but they may need a 
sub check such as
EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or 
EVP_PKEY_pairwise_check (or some combination of those).
Keys (and certs) that are received from another entity should be validated 
unless there is some other mechanism for establishing that the key is trusted.


> On 12 Nov 2020, at 12:14 am, Nicola Tuveri  wrote:
> 
> 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 1.1.1.
> 
> 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 omitting the validation pass that should
> be required in any serious use of the API.
> 
> `EVP_PKEY_check()`
> (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$
>  ) is
> one of the many places in 1.1.1 where both the documentation and the
> behavior assume that an `EVP_PKEY` object is a keypair.
> Even in the version used by the user that posted the issue, running
> `EVP_PKEY_check()` on the created key would have revealed that the
> user was abusing the API.
> 
> The "lack of enforcement" argument, that was partially at the base of
> formulating the vote text as it is, and conditioned our votes, seems
> to me an intentional design choice, as part of preferring the usage
> pattern "validate once, and reuse many times": for performance reasons
> we are not running `EVP_PKEY_check()` on every single key loaded from
> a PEM file or created by the user, but there is an assumption that the
> user did validate at least once the key material using
> `EVP_PKEY_check()` or `openssl pkey -check`.
> So enforcement was never lacking, but it was relegated together with
> more expensive checks, into functions that the user should execute at
> least once, possibly according to well documented security policies
> concerning the management of key material in transit and at rest.
> 
> Omitting the `EVP_PKEY_check()` in the reproducer and the user
> application, would for example allow me to write a DoS attack: the
> secret scalar could easily be hand-picked to trigger an endless loop
> in the sign operation.
> 
> 
> --
> 
> Nicola
> 
> 
> 
> On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell  wrote:
>> 
>> 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 turns out that in the EC implementation in 1.1.1 it
>> was perfectly possible to create an EVP_PKEY with only a private key and
>> no public key - and it was also possible to use such an EVP_PKEY in a
>> signing operation.
>> 
>> The current 3.0 code in master introduced an explicit check (in line
>> with the long held assumption) that the public key was present and
>> rejected keys where this was not the case. This caused a backwards
>> compatibility break for some users (as discussed at length in #12612).
>> 
>> The OTC discussed a proposal that we should relax our conceptual model
>> in this regards and conceptually allow EVP_PKEYs to exist that only have
>> the private component without the public component - although individual
>> algorithm implementations may still require both.
>> 
>> It is possible to automatically generate the public component from the
>> private for many algorithms, although this may come at a performance and
>> (potentially) a security cost.
>> 
>> 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 behaviour between 1.1.1 and 3.0.
>> 
>> The vote text is as follows:
>> 
>> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
>> * relax the conceptual model to allow private keys to exist without public
>>  components;
>> * all implementations apart from EC require the public component to be
>> present;
>> * relax implementation for EC key management to allow private keys that
>> do not
>>  contain public keys 

Re: OTC VOTE: EVP_PKEY private/public key components

[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 1.1.1.

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 omitting the validation pass that should
be required in any serious use of the API.

`EVP_PKEY_check()`
(https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is
one of the many places in 1.1.1 where both the documentation and the
behavior assume that an `EVP_PKEY` object is a keypair.
Even in the version used by the user that posted the issue, running
`EVP_PKEY_check()` on the created key would have revealed that the
user was abusing the API.

The "lack of enforcement" argument, that was partially at the base of
formulating the vote text as it is, and conditioned our votes, seems
to me an intentional design choice, as part of preferring the usage
pattern "validate once, and reuse many times": for performance reasons
we are not running `EVP_PKEY_check()` on every single key loaded from
a PEM file or created by the user, but there is an assumption that the
user did validate at least once the key material using
`EVP_PKEY_check()` or `openssl pkey -check`.
So enforcement was never lacking, but it was relegated together with
more expensive checks, into functions that the user should execute at
least once, possibly according to well documented security policies
concerning the management of key material in transit and at rest.

Omitting the `EVP_PKEY_check()` in the reproducer and the user
application, would for example allow me to write a DoS attack: the
secret scalar could easily be hand-picked to trigger an endless loop
in the sign operation.


--

Nicola



On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell  wrote:
>
> 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 turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
>
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
>
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
>
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
>
> 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 behaviour between 1.1.1 and 3.0.
>
> The vote text is as follows:
>
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
>
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[  ]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [-1]

Re: OTC VOTE: EVP_PKEY private/public key components

[Tim Hudson]

-1

As I said in the OTC meeting, I agree we should change the conceptual model
to not require a private key to be a super-set of a public key; however I
do not think we should introduce key-type specific behaviour in this area -
i.e. if it makes sense to change the model then it should apply equally to
(for example) RSA keys as to EC keys.

Tim.

On Tue, Nov 10, 2020 at 2:20 AM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> 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:
> >
> > 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 turns out that in the EC implementation in 1.1.1 it
> > was perfectly possible to create an EVP_PKEY with only a private key and
> > no public key - and it was also possible to use such an EVP_PKEY in a
> > signing operation.
> >
> > The current 3.0 code in master introduced an explicit check (in line
> > with the long held assumption) that the public key was present and
> > rejected keys where this was not the case. This caused a backwards
> > compatibility break for some users (as discussed at length in #12612).
> >
> > The OTC discussed a proposal that we should relax our conceptual model
> > in this regards and conceptually allow EVP_PKEYs to exist that only have
> > the private component without the public component - although individual
> > algorithm implementations may still require both.
> >
> > It is possible to automatically generate the public component from the
> > private for many algorithms, although this may come at a performance and
> > (potentially) a security cost.
> >
> > 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 behaviour between 1.1.1 and 3.0.
> >
> > The vote text is as follows:
> >
> > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> > * relax the conceptual model to allow private keys to exist without
> public
> >   components;
> > * all implementations apart from EC require the public component to be
> > present;
> > * relax implementation for EC key management to allow private keys that
> > do not
> >   contain public keys and
> > * our decoders unconditionally generate the public key (where possible).
> >
> > Proposed by Matt Caswell
> > Public: yes
> > opened: 2020-11-03
> > closed: 2020-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> >
> >   Matt   [+1]
> >   Mark   [  ]
> >   Pauli  [+1]
> >   Viktor [  ]
> >   Tim[  ]
> >   Richard[+1]
> >   Shane  [+1]
> >   Tomas  [+1]
> >   Kurt   [  ]
> >   Matthias   [  ]
> >   Nicola [-1]
>
>

RE: OTC VOTE: EVP_PKEY private/public key components

[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:
> 
> 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 turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
> 
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
> 
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
> 
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
> 
> 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 behaviour between 1.1.1 and 3.0.
> 
> The vote text is as follows:
> 
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
> 
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[  ]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [-1]



smime.p7s
Description: S/MIME cryptographic signature

OTC VOTE: EVP_PKEY private/public key components

[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 turns out that in the EC implementation in 1.1.1 it
was perfectly possible to create an EVP_PKEY with only a private key and
no public key - and it was also possible to use such an EVP_PKEY in a
signing operation.

The current 3.0 code in master introduced an explicit check (in line
with the long held assumption) that the public key was present and
rejected keys where this was not the case. This caused a backwards
compatibility break for some users (as discussed at length in #12612).

The OTC discussed a proposal that we should relax our conceptual model
in this regards and conceptually allow EVP_PKEYs to exist that only have
the private component without the public component - although individual
algorithm implementations may still require both.

It is possible to automatically generate the public component from the
private for many algorithms, although this may come at a performance and
(potentially) a security cost.

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 behaviour between 1.1.1 and 3.0.

The vote text is as follows:

topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
* relax the conceptual model to allow private keys to exist without public
  components;
* all implementations apart from EC require the public component to be
present;
* relax implementation for EC key management to allow private keys that
do not
  contain public keys and
* our decoders unconditionally generate the public key (where possible).

Proposed by Matt Caswell
Public: yes
opened: 2020-11-03
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Matt   [+1]
  Mark   [  ]
  Pauli  [+1]
  Viktor [  ]
  Tim[  ]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [-1]