Re: 3.0.3 - EVP_EC_gen() segfault without init

[Tomas Mraz]

Yes, this is unfortunately a bug in 3.0.3 release. Calling
OPENSSL_init_crypto should not be necessary.

Tomas Mraz

On Wed, 2022-05-04 at 21:58 +0200, Klaus Keppler wrote:
> Hello,
> 
> yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of
> our 
> unit tests crash.
> 
> I've boiled the problem down to the following example code:
> 
> ---cut---
> #include 
> #include 
> #include 
> 
> int main(int argc, const char *argv[]) {
>  //OPENSSL_init_crypto(0, NULL);
>  if (! EVP_EC_gen("P-384")) return -1;
>  return 0;
> }
> ---/cut---
> 
> Compile with:
> 
>    gcc -Wall -Werror -pedantic -o test test.c -lcrypto
> 
> With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a 
> segmentation fault during a string comparison within
> EVP_PKEY_Q_keygen 
> (EVP_EC_gen is just a macro).
> 
> I assume that the curve names are not properly initialized, when you 
> uncomment the call to "OPENSSL_init_crypto()", everything works just
> fine.
> 
> The documentation [1] of OPENSSL_init_crypto() states that explicit 
> initialization is not required. Man page of EVP_EC_gen [2] says
> nothing 
> about initialization.
> Considering that 3.0.3 is only a minor update and 3.0.2 worked as 
> expected, we might have hit a bug. If this (above) is "just" a usage 
> error, the documentation should describe in which cases an explicit 
> initialization is required.
> 
> Anyway, thank you for all your efforts!
> 
> Best regards
> 
>     -Klaus Keppler
> 
> 
> [1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
> [2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html

-- 
Tomáš Mráz, OpenSSL

Re: 3.0.3 - EVP_EC_gen() segfault without init

[Klaus Keppler]

Oh sorry, forgot to say that.

It's x86-64, compiled on Debian 10.12 (GCC 8.3.0) and CentOS 7 (GCC 
8.3.1) - other distributions/GCC versions not tested yet.


OpenSSL was compiled with common hardening flags:
CFLAGS="-fstack-protector --param ssp-buffer-size=4 -fPIC -O2"
CPPFLAGS="-D_FORTIFY_SOURCE=2"

arm64 and armhf also seem to be not affected (at least our unit tests 
there passed).


Best regards

   -Klaus


Am 04.05.2022 um 22:07 schrieb Blumenthal, Uri - 0553 - MITLL:

What platform?

$ bat ossl3-tst.c
───┬──
│ File: ossl3-tst.c
│ Size: 216 B
───┼──
1   │ #include 
2   │ #include 
3   │ #include 
4   │
5   │ int main(int argc, const char *argv[]) {
6   │  //OPENSSL_init_crypto(0, NULL);
7   │  if (! EVP_EC_gen("P-384")) return -1;
8   │  return 0;
9   │ }
───┴──
$ gcc -Wall -Werror -pedantic -o ossl3-tst ossl3-tst.c -I/opt/local/include 
-L/opt/local/lib -lcrypto
$ ./ossl3-tst
$

Above is on MacOS Monterey with GCC-11.
--
V/R,
Uri
  
There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

  -  C. A. R. Hoare
  


On 5/4/22, 15:58, "openssl-users on behalf of Klaus Keppler" 
 wrote:

 Hello,

 yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of our
 unit tests crash.

 I've boiled the problem down to the following example code:

 ---cut---
 #include 
 #include 
 #include 

 int main(int argc, const char *argv[]) {
  //OPENSSL_init_crypto(0, NULL);
  if (! EVP_EC_gen("P-384")) return -1;
  return 0;
 }
 ---/cut---

 Compile with:

gcc -Wall -Werror -pedantic -o test test.c -lcrypto

 With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a
 segmentation fault during a string comparison within EVP_PKEY_Q_keygen
 (EVP_EC_gen is just a macro).

 I assume that the curve names are not properly initialized, when you
 uncomment the call to "OPENSSL_init_crypto()", everything works just fine.

 The documentation [1] of OPENSSL_init_crypto() states that explicit
 initialization is not required. Man page of EVP_EC_gen [2] says nothing
 about initialization.
 Considering that 3.0.3 is only a minor update and 3.0.2 worked as
 expected, we might have hit a bug. If this (above) is "just" a usage
 error, the documentation should describe in which cases an explicit
 initialization is required.

 Anyway, thank you for all your efforts!

 Best regards

 -Klaus Keppler


 [1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
 [2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html

Re: 3.0.3 - EVP_EC_gen() segfault without init

[Blumenthal, Uri - 0553 - MITLL]

What platform?

$ bat ossl3-tst.c
───┬──
   │ File: ossl3-tst.c
   │ Size: 216 B
───┼──
   1   │ #include 
   2   │ #include 
   3   │ #include 
   4   │ 
   5   │ int main(int argc, const char *argv[]) {
   6   │  //OPENSSL_init_crypto(0, NULL);
   7   │  if (! EVP_EC_gen("P-384")) return -1;
   8   │  return 0;
   9   │ }
───┴──
$ gcc -Wall -Werror -pedantic -o ossl3-tst ossl3-tst.c -I/opt/local/include 
-L/opt/local/lib -lcrypto
$ ./ossl3-tst 
$

Above is on MacOS Monterey with GCC-11.
--
V/R,
Uri
 
There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 5/4/22, 15:58, "openssl-users on behalf of Klaus Keppler" 
 wrote:

Hello,

yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of our 
unit tests crash.

I've boiled the problem down to the following example code:

---cut---
#include 
#include 
#include 

int main(int argc, const char *argv[]) {
 //OPENSSL_init_crypto(0, NULL);
 if (! EVP_EC_gen("P-384")) return -1;
 return 0;
}
---/cut---

Compile with:

   gcc -Wall -Werror -pedantic -o test test.c -lcrypto

With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a 
segmentation fault during a string comparison within EVP_PKEY_Q_keygen 
(EVP_EC_gen is just a macro).

I assume that the curve names are not properly initialized, when you 
uncomment the call to "OPENSSL_init_crypto()", everything works just fine.

The documentation [1] of OPENSSL_init_crypto() states that explicit 
initialization is not required. Man page of EVP_EC_gen [2] says nothing 
about initialization.
Considering that 3.0.3 is only a minor update and 3.0.2 worked as 
expected, we might have hit a bug. If this (above) is "just" a usage 
error, the documentation should describe in which cases an explicit 
initialization is required.

Anyway, thank you for all your efforts!

Best regards

-Klaus Keppler


[1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
[2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html


smime.p7s
Description: S/MIME cryptographic signature

3.0.3 - EVP_EC_gen() segfault without init

[Klaus Keppler]

Hello,

yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of our 
unit tests crash.


I've boiled the problem down to the following example code:

---cut---
#include 
#include 
#include 

int main(int argc, const char *argv[]) {
//OPENSSL_init_crypto(0, NULL);
if (! EVP_EC_gen("P-384")) return -1;
return 0;
}
---/cut---

Compile with:

  gcc -Wall -Werror -pedantic -o test test.c -lcrypto

With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a 
segmentation fault during a string comparison within EVP_PKEY_Q_keygen 
(EVP_EC_gen is just a macro).


I assume that the curve names are not properly initialized, when you 
uncomment the call to "OPENSSL_init_crypto()", everything works just fine.


The documentation [1] of OPENSSL_init_crypto() states that explicit 
initialization is not required. Man page of EVP_EC_gen [2] says nothing 
about initialization.
Considering that 3.0.3 is only a minor update and 3.0.2 worked as 
expected, we might have hit a bug. If this (above) is "just" a usage 
error, the documentation should describe in which cases an explicit 
initialization is required.


Anyway, thank you for all your efforts!

Best regards

   -Klaus Keppler


[1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
[2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html

Re: EC_POINT_get_affine_coordinates replacement in 3.0

[Matt Caswell]

On 03/05/2022 23:29, Kory Hamzeh wrote:
You would have to use EVP_PKEY key type. You can use EVP_PKEY_get* to 
get key params.


Yes this is probably the best way to do this.

Specifically you can use the function EVP_PKEY_get_bn_param() documented 
here:


https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_get_bn_param.html

The params you want are called OSSL_PKEY_PARAM_EC_PUB_X and 
OSSL_PKEY_PARAM_EC_PUB_Y as documented on this page:


https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html

Matt






On May 3, 2022, at 1:56 PM, Chris Bare > wrote:


Thanks, I'll check those out.

On Tue, May 3, 2022 at 4:53 PM William Roberts 
mailto:bill.c.robe...@gmail.com>> wrote:


On Tue, May 3, 2022 at 3:18 PM Chris Bare mailto:chris.b...@gmail.com>> wrote:
>
>
> On Tue, May 3, 2022 at 3:10 PM William Roberts
mailto:bill.c.robe...@gmail.com>> wrote:
>>
>> On Tue, May 3, 2022 at 1:14 PM Chris Bare mailto:chris.b...@gmail.com>> wrote:
>> >
>> > I'm converting some openssl 1.0 code to 3.0 and I don't know
how to get the coordinates
>> > in a 3.0 way.
>> > The old code is:
>> > BN_CTX *ctx = BN_CTX_new ();
>> > BIGNUM *X = NULL, *Y = NULL;
>> > const EC_POINT *pubkey;
>> > const EC_GROUP *group;
>> > BN_CTX_start (ctx);
>> > X = BN_CTX_get (ctx);
>> > Y = BN_CTX_get (ctx);
>> > pubkey = EC_KEY_get0_public_key ((EC_KEY *) EVP_PKEY_get0
(pkey));
>> > group = EC_KEY_get0_group ((EC_KEY *) EVP_PKEY_get0
(cvr->sm_pkey));
>> > EC_POINT_get_affine_coordinates_GFp (group, pubkey, X, Y, ctx)
>> >
>> > What would be the 3.0 way to get X and Y without using
deprecated functions?
>>
>> For EC_POINT_get_affine_coordinates_GFp it goes to
>> EC_POINT_get_affine_coordinates, see:
>>   -

https://www.openssl.org/docs/man3.0/man3/EC_POINT_get_affine_coordinates.html


>>
>> Offhand I don't see any other deprecated functions, was that
the only one?
>>
>> Thanks,
>> Bill
>
>
> all the EC_KEY_get0_ functions are deprecated. Is there a new
way to access the internals of
> the opaque structures, or am I stuck with the deprecated ones
for this?

I think you want the from and to data routines that provide the
components from an EVP PKEY or produce an EVP_PKEY
from the components:
  - https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_todata.html

  -
https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html




--
Chris Bare

Re: [EXTERNAL] Using openssl-rsautl for verifying signatures.

[Erwann Abalea via openssl-users]

Bonjour,

The ASN.1 structure (it's a DigestInfo) is part of the PKCS#1 v1.5 padding
for signature operations.
PKCS#1v1.5 is rewritten in RFC2313.

Using the command line tool, you can reproduce this:

echo -n "Mary had a little lamb." > datatosign

either one of the following can be used to sign data:
  openssl dgst -sha1 -sign tests/keys/rsa_key1.key datatosign > signing
  openssl pkeyutl -inkey tests/keys/rsa_key1.key -in <(openssl dgst -sha1
-binary datatosign) -sign -pkeyopt digest:sha1 > signing

and you can display the signature either way (this will not "verify", it
will only perform the RSA verify operation with PKCS#1v1.5 padding, without
checking the validity or even if what has been signed is a DigestInfo
structure, and output the result of the RSA operation):
  openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -in signing
-asn1parse
  openssl pkeyutl -verifyrecover -inkey tests/keys/rsa_key1.pub -pubin
-in signing -asn1parse

or you can actually verify the thing without displaying the result of the
RSA verify crypto operation:
  openssl pkeyutl -verify -inkey tests/keys/rsa_key1.pub -pubin -in
<(openssl dgst -sha1 -binary datatosign) -sigfile signing -pkeyopt
digest:sha1
  openssl dgst -verify tests/keys/rsa_key1.pub -signature signing
-sha1 datatosign

On Wed, May 4, 2022 at 7:16 AM Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:

> Hi,
>
> I did the following in trying to build some validation steps to use
> against my own rewrite of the crypto functions in Asterisk (to use
> EVP-PKEY).
>
> % echo -n "Mary had a little lamb." | openssl sha1 -binary > digest
>
> % od -t x1 digest
> 000 4e 07 b8 c7 aa f2 a4 ed 4c e3 9e 76 f6 5d 2a 04
> 020 bd ef 57 00
> 024
>
> % openssl rsautl -sign -inkey tests/keys/rsa_key1.key -pkcs -in digest >
> signing
>
> % openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -pkcs -in
> signing > digest2
>
> % od -t x1 digest
> 000 4e 07 b8 c7 aa f2 a4 ed 4c e3 9e 76 f6 5d 2a 04
> 020 bd ef 57 00
> 024
>
> And all of that looks good.
>
> But when I take the result of calling:
>
> const char msg[] = "Mary had a little lamb.";
> unsigned msglen = sizeof(msg) - 1;
> char digest[20];
>
> /* Calculate digest of message */
> SHA1((unsigned char *)msg, msglen, digest);
>
> res = RSA_sign(NID_sha1, digest, sizeof(digest), dsig, ,
> key->rsa);
>
> And write that (dsig, siglen) to a file (signing2) and then try to verify
> that, I get very different results:
>
> openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -pkcs -in
> signing2  -asn1parse
> 0:d=0  hl=2 l=  33 cons: SEQUENCE
> 2:d=1  hl=2 l=   9 cons:  SEQUENCE
> 4:d=2  hl=2 l=   5 prim:   OBJECT:sha1
>11:d=2  hl=2 l=   0 prim:   NULL
>13:d=1  hl=2 l=  20 prim:  OCTET STRING
>    - 4e 07 b8 c7 aa f2 a4 ed-4c e3 9e 76 f6 5d 2a 04
>  N...L..v.]*.
>   0010 - bd ef 57 00   ..W.
>
> Why is RSA_sign() wrapping the signature in ASN.1?
>
> Or, put a different way, how do I reproduce what RSA_sign() is doing from
> the command line?
>
> Is there another command that does RSA signing besides rsautl?
>
> Thanks,
>
> -Philip
>
>
>

-- 
Cordialement,
Erwann Abalea.