RE: OpenSSL Cookbook is being updated soon

[Dr. Matthias St. Pierre]

typo: “your user base” -> “our user base”

From: openssl-project  On Behalf Of Dr. 
Matthias St. Pierre
Sent: Monday, November 16, 2020 9:08 PM
To: Ivan Ristic ; openssl-project@openssl.org
Subject: RE: OpenSSL Cookbook is being updated soon

Ivan,

thank you very much for giving us the opportunity to preview your next 
publication of the OpenSSL cookbook. Even if your mail was unanswered (until 
know), I’m sure your announcement did not go unnoticed.

I would like to take the opportunity to thank you for your continuous efforts 
during the past years to provide the OpenSSL community with an excellent 
introduction to the OpenSSL command line tool. It has always been available as 
a free download and is a valuable source of information for your user base. And 
it’s excellent news that there is an update coming. Enough reasons IMHO to 
propose you as an “OpenSSL Team member h.c.” if such a role would already exist 
in our bylaws (maybe we should add it ).

Regards,

Matthias

@openssl/committers: please take the time to take a look at the preprint and 
provide your feedback.


From: openssl-project 
mailto:openssl-project-boun...@openssl.org>>
 On Behalf Of Ivan Ristic
Sent: Friday, November 6, 2020 11:29 AM
To: openssl-project@openssl.org
Subject: OpenSSL Cookbook is being updated soon

Apologies for starting a new thread, but I had no previous message to reply to. 
Matt alerted me to the mention of OpenSSL Cookbook here and I was previously 
not on this list.

I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed 
the 3rd edition. This time I had Matt help me as a technical reviewer and that 
led to many improvements. We're currently updating our web site and will 
release the new edition as soon as that's done.

The 3rd edition required many changes because of TLS 1.3. Now that it's done, 
going forward I will aim for continuous updates as needed.

Additionally, we wish to make the content more useful by splitting it into 
smaller chunks. At the moment, it's presented as one page per chapter, which is 
not ideal. We will look into this at some point after the release.

If you'd like to see the 3rd edition before it's officially out, you can 
actually get it immediately by registering for an account here 
https://www.feistyduck.com/account/register If you already have an account, it 
should be offered to you at the bottom of the library page 
https://www.feistyduck.com/library/ I would certainly welcome any thoughts 
about the content and the possible improvements. The scope is generally 
command-line usage.

--
Ivan


smime.p7s
Description: S/MIME cryptographic signature

RE: OpenSSL Cookbook is being updated soon

[Dr. Matthias St. Pierre]

Ivan,

thank you very much for giving us the opportunity to preview your next 
publication of the OpenSSL cookbook. Even if your mail was unanswered (until 
know), I’m sure your announcement did not go unnoticed.

I would like to take the opportunity to thank you for your continuous efforts 
during the past years to provide the OpenSSL community with an excellent 
introduction to the OpenSSL command line tool. It has always been available as 
a free download and is a valuable source of information for your user base. And 
it’s excellent news that there is an update coming. Enough reasons IMHO to 
propose you as an “OpenSSL Team member h.c.” if such a role would already exist 
in our bylaws (maybe we should add it ).

Regards,

Matthias

@openssl/committers: please take the time to take a look at the preprint and 
provide your feedback.


From: openssl-project  On Behalf Of Ivan 
Ristic
Sent: Friday, November 6, 2020 11:29 AM
To: openssl-project@openssl.org
Subject: OpenSSL Cookbook is being updated soon

Apologies for starting a new thread, but I had no previous message to reply to. 
Matt alerted me to the mention of OpenSSL Cookbook here and I was previously 
not on this list.

I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed 
the 3rd edition. This time I had Matt help me as a technical reviewer and that 
led to many improvements. We're currently updating our web site and will 
release the new edition as soon as that's done.

The 3rd edition required many changes because of TLS 1.3. Now that it's done, 
going forward I will aim for continuous updates as needed.

Additionally, we wish to make the content more useful by splitting it into 
smaller chunks. At the moment, it's presented as one page per chapter, which is 
not ideal. We will look into this at some point after the release.

If you'd like to see the 3rd edition before it's officially out, you can 
actually get it immediately by registering for an account here 
https://www.feistyduck.com/account/register If you already have an account, it 
should be offered to you at the bottom of the library page 
https://www.feistyduck.com/library/ I would certainly welcome any thoughts 
about the content and the possible improvements. The scope is generally 
command-line usage.

--
Ivan


smime.p7s
Description: S/MIME cryptographic signature

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: Introducing Paul Nelson

[Nicola Tuveri]

That's great news!



Welcome Paul!


Nicola

On Mon, Nov 16, 2020 at 7:15 PM Matt Caswell  wrote:
>
> You may recall that some while ago we posted a blog where we were
> looking for an Administrator and Manager to help run the project:
>
> https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/
>
> I am delighted to be able to tell you that we have appointed Paul Nelson
> to this position. He is starting in the role today. I will let him
> introduce himself once he has managed to get his email access sorted!
>
> I'd like to welcome Paul to the project!
>
> Matt
>

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/

Introducing Paul Nelson

[Matt Caswell]

You may recall that some while ago we posted a blog where we were
looking for an Administrator and Manager to help run the project:

https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/

I am delighted to be able to tell you that we have appointed Paul Nelson
to this position. He is starting in the role today. I will let him
introduce himself once he has managed to get his email access sorted!

I'd like to welcome Paul to the project!

Matt

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

Job Change

[Dmitry Belyavsky]

Dear colleagues,

If everything is OK, I join the RedHat team on December 1. As it's planned
now, I join the department where Tomas Mraz works.

I strongly suppose that being an OpenSSL committer was a significant
argument for the RedHat to send me an offer, and hope I'll be able to
continue my activity as a committer.

-- 
SY, Dmitry Belyavsky