From chain78 at 163.com  Tue Jun  2 08:25:24 2020
From: chain78 at 163.com (=?GBK?B?yfK6o7vN?=)
Date: Tue, 2 Jun 2020 16:25:24 +0800 (CST)
Subject: error:1012606B:elliptic curve
 routines:EC_POINT_set_affine_coordinates:point is not on curve
Message-ID: <392f3829.6903.17274229a73.Coremail.chain78@163.com>



openssl version: openssl-1.1.1a
os:linux
Hardware platform: imx6uul
Compiler Details:arm-poky-linux-gnueabi-gcc 5.3.0 


Subject: error:1012606B:elliptic curve routines:EC_POINT_set_affine_coordinates:point is not on curve

I use https with libcurl static library on imx6ull board. It return "error:1012606B:elliptic curve routines:EC_POINT_set_affine_coordinates:point is not on curve" this error. I found this error is in openssl.
How can I to do ?


Openssl Build:
./config --prefix=/home/share/lib/openssl  no-asm no-shared
make
make install


Curl Build:
export PATH=/root/perl5/perlbrew/bin:/root/perl5/perlbrew/perls/perl-5.20.1/bin:$PATH
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/share/lib/openssl/lib/pkgconfig:/home/share/lib/zlib/lib/pkgconfig
CPPFLAGS="-I/home/share/lib/openssl/include" LDFLAGS="-L/home/share/lib/openssl/lib" ./configure --with-ssl --host=x86_64-pokysdk-linux --with-zlib --prefix=/home/share/lib/curl
make
make install


Code:
#include <stdio.h>

#include <curl/curl.h>




int main(void)

{

  CURL *curl;

  CURLcode res;




  curl_global_init(CURL_GLOBAL_DEFAULT);




  curl = curl_easy_init();

  if(curl) {

    curl_easy_setopt(curl, CURLOPT_URL, "https://www.baidu.com");




    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);

    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);

curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);

    res = curl_easy_perform(curl);

    if(res != CURLE_OK)

      fprintf(stderr, "curl_easy_perform() failed: %s\n",

              curl_easy_strerror(res));

    curl_easy_cleanup(curl);

  }




  curl_global_cleanup();




  return 0;

}





 





 





 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200602/2c61ce09/attachment.html>

From openssl at eckner.net  Wed Jun  3 09:26:05 2020
From: openssl at eckner.net (Erich Eckner)
Date: Wed, 3 Jun 2020 11:26:05 +0200 (CEST)
Subject: distributed secret key
In-Reply-To: <CAMm+LwjBVHayJ+JaOfg_eYxuMjQVoaUCTpLOjv7wDjFBcnvJHw@mail.gmail.com>
References: <alpine.LNX.2.22.432.2005241144560.14898@desk.ddns.eckner.net>
 <10773.1590337211@localhost>
 <CAMm+LwjhZ98fanZ8XqSjspxQU+nB2zkbCekn6MWRw-dgRM0QGQ@mail.gmail.com>
 <alpine.LNX.2.22.432.2005242144030.10594@desk.ddns.eckner.net>
 <CAMm+LwjBVHayJ+JaOfg_eYxuMjQVoaUCTpLOjv7wDjFBcnvJHw@mail.gmail.com>
Message-ID: <alpine.LNX.2.22.432.2006030929430.180946@nlopc43.ioq.uni-jena.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Phillip,

@all: If this goes too far off-topic for the openssl mailing list, let me 
know, and I'll continue the discussion off-mailing-list.

On Mon, 25 May 2020, Phillip Hallam-Baker wrote:

> 
> 
> On Sun, May 24, 2020 at 4:17 PM Erich Eckner <openssl at eckner.net> wrote:
>
>       On Sun, 24 May 2020, Phillip Hallam-Baker wrote:
>
>       >
>       > I do indeed have running code but not (necessarily) for this
>       particular
>       > variant (yet).
>       >
>       > What I have right now is a scheme that allows
>       >
>       > 1)? An existing secret key to be split into (n,t) shares where
>       the threshold
>       > t < number of shares.
>
>       I suppose, this includes also the part to use/reconstruct the
>       secret key?
>       May I ask, what we need to do to sign something with the
>       splitted key?
> 
> 
> It is all explained in the draft but basically for the n=t version, you have
> a minimum of two rounds. In round 1, everyone has to agree on their secret
> key blinding value k_i and make a commitment to R_i = k_i.P. Then the dealer
> has to gather up the commitments to calculate the value R as their sum -
> from which the message digest value can be calculated. Then each signer just
> signs as normal.
> 
> It is all very straightforward. Very little has to change.
> 
> To do n<t then you have to calculate the lagrange coefficient and multiply
> your secret key by that factor. Again explained in the draft.
>

Sry, I missed that before. I have just read the draft, now.

> ?
> 
> Nope, I haven't got a fully finished scheme for the Shamir Secret Sharing
> t<n version (yet) that begins with a distributed key generation scheme.?

ok, I see.

> 
> In fact, I have yet to fully grock how that starts. Do we have n people
> participate or t? I can carry the math part. But there seems to be this gap
> when I try to move to ceremony...

Well, there is only t parts of information in there (e.g. if t parties 
would share their secrets, the other n-t secrets could be reconstructed). 
So one way would be to have t parties "settle on a shared key" and 
calculate the n-t other secrets - but this creates some asymmetry between 
the trust in the parties. Maybe it's instead possible to have n parties 
create secrets, and then "project" this n-dimensional key onto some 
t-dimensional hyperplane without actually sending the secrets around? 
(This might work with the "n points of a polinomial of degree t-1" 
approach, too: "projecting" would refer to some kind of fitting, there)

So everyone would do:
1. create some secret
2. send some information around
3. calculate the component of "his coordinate" of the perpendicular to the 
t-dimensional hyperplane
4. subtract that from his secret

> 
> 
> What are you hoping to use this CA for? It it is to issue WebPKI (i.e. get
> your root embedded in a browser) certs then CABForum writes the rules. They
> have picked a set of algorithms/ curves they like.?

Yes, it should become the root CA for OpenNIC to certify webservers. At 
some point (very long shot), it might get included in browers, but I 
honestly do not expect this to happen within the next decade ;-) 
Nevertheless, we would like to avoid any trivially-avoidable obstacles and 
create a CA that is as much conformant to the rules as possible :-)

> 
> But you have to use HSMs and that is a bigger constraint and none of that
> supports threshold - or is likely to for some time.

Hmm, I was afraid, we would need HSMs, too. Your draft mentions, that one 
of the participants could be an HSM - but I guess, this a) is not (yet) 
implemented and b) does not scale to more than 1 HSM because of the 
statelessness of the HSM (one would need at least n-t+1 HSMs, to satisfy 
the "have to use HSMs" condition, I guess). Am I right? If so, we will 
refrain from our bold goal of being included in browser bundles and simply 
not use HSMs.

> 
>
>       Ok, so we will probably say good bye to the
>       separately-created-key
>       approach and split a given secret key which we will afterwards
>       securely
>       erase (and only keep the parts).
> 
> 
> That is the simplest one as far as ceremony goes.
> 
>
>       > For the set of applications I care about, this attack is not
>       actually that
>       > important because while Mallet knows the secret key, he is the
>       only person
>       > who does. And so he won't be able to respond to any composite
>       signature
>       > request with a valid answer.?
>
>       But he can still sign anything he wants, right? Or does he never
>       see the
>       csr, but only the "preprocessed" csr, so he cannot sign it?
> 
> 
> Well he can sign anything he wants but why is that key accredited to
> anything else? Why is it considered to be a trustworthy key for that group
> of signers?
> 
> This is what I am trying to get at with mention of 'CSR' - there has to be
> some 'get trusted' process.
> 
> ?
>       >
>       > So for PKIX type applications, this is self defeating as only
>       Mallet can
>       > generate the CSR.
>
>       Why would they want to create CSRs? In our case, this is
>       intended to be
>       the Root CA.
> 
> 
> Its been over a decade since I last stood up a production CA. It is really a
> matter of ceremony design. Having the offline root first generate a CSR and
> then accept the CSR by signing it means that the ceremony for generating the
> self signed root is the same as that for the subordinates for a start.?

Ah, I see: When creating the self-signature of the CA itself, the 
threshold signature will fail, because the keys do not fit. Although 
Mallet can create a valid self-signature, no one would use it, because 
it's clear, that this was not created by the threshold signature 
algorithm.


Can you please share some running code, that implements the t<n threshold 
signing and the key splitting (from a single key)?


regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7XbK4ACgkQCu7JB1Xa
e1qXAQ//SpsK440wb2IFd8ikTliYlnAdOLyu7LejOVAbAJv7+ZEAvMBjI3NVzRXd
RSO873ROXNeCZNLUpmktreSD6vZwnrDaingGZLTYY7JiIZ4GVORYcENXZlLmCzUg
842j8rjN7kYFoef5qqzB78BsQDmRfat5YZmroWPs2Oul9oyxZR715i0zWPFSHYkO
kFWhTg0jiYFkMyGAmgSw5d+zkxEFnwzVlTFBWKVwqvzzahBg2+NdwdI9fTg4OG2+
xEa/BjmhKSNXzpaCTRdknMvZtwENYmuqMs+78UFyYS4pjit4FDIL40uStpNvpea7
BZK+jRDIGjMvUL8Mq2YOWk57POZFsj5zil+CRkAmb639nAtj1GqBr9cCh5DVZqCt
ZihcGRxf6VKegilhvo1272BSyUlTo92ldebw5lVWLPxNuWRv2mibNuD3JXaC7TKd
FHW10iTiUHQI+Ztpl/DT3FnRLltd8w3K/uqFTI0rmdg1vqXDWLj2KCoBzXscv6Gz
/yVOqQslvMIDQCtPkP4g/nBhgYQ9/oNeeULib3VOgUFoTQeTGsi+xGavW/iEH/lG
EnSKFszucQlqHx2ylnjSXY4KVGnltCmer8KGXnKB8qXsA/uORUOAghC3ckieCeR1
bH3/w/Y35ui8952sH6ipVnh2e2FmAHeQ/lKOytg4rdjMyb0cLRk=
=Y1G5
-----END PGP SIGNATURE-----

From ca+ssl-users at esmtp.org  Wed Jun  3 17:05:32 2020
From: ca+ssl-users at esmtp.org (Claus Assmann)
Date: Wed, 3 Jun 2020 19:05:32 +0200
Subject: 3.0.0-alpha2: openssl ciphers MEDIUM empty?
Message-ID: <20200603170532.GA47785@kiel.esmtp.org>

Just curious: Why is the output of
openssl ciphers MEDIUM
"empty" for 3.0.0.a2?
Error in cipher list
00:00:00:00:error:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2705:

Using 1.1.1 lists several, and at least
TLS_AES_128_GCM_SHA256
is also listed by
openssl-3.0.0.a2 ciphers

Has the "classification" of ciphers changed?
I didn't see anything obvious in CHANGES.

From bkaduk at akamai.com  Wed Jun  3 23:39:55 2020
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 3 Jun 2020 16:39:55 -0700
Subject: 3.0.0-alpha2: openssl ciphers MEDIUM empty?
In-Reply-To: <20200603170532.GA47785@kiel.esmtp.org>
References: <20200603170532.GA47785@kiel.esmtp.org>
Message-ID: <20200603233955.GV3811@akamai.com>

On Wed, Jun 03, 2020 at 07:05:32PM +0200, Claus Assmann wrote:
> Just curious: Why is the output of
> openssl ciphers MEDIUM
> "empty" for 3.0.0.a2?

There are no ciphers available by default that are at the MEDIUM
level (which, to be honest, does not make a huge amount of sense at this
point anyway -- there's not a clear spot between "good" and "bad" to
bucket things into).

> Error in cipher list
> 00:00:00:00:error:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2705:
> 
> Using 1.1.1 lists several, and at least
> TLS_AES_128_GCM_SHA256
> is also listed by
> openssl-3.0.0.a2 ciphers

TLS_* are TLS 1.3 ciphers, which in the parlance of openssl configuration
are known as "ciphersuites" (vs. "cipher list"), and are not affected
by the "cipher list" that you provide via SSL_CTX_set_cipher_list().

My
$ openssl version
OpenSSL 1.1.1  11 Sep 2018
only reports the TLS 1.3 ciphersuites and some SEED ciphers for an
input of MEDIUM, and IIRC the SEED ciphers have been foisted off to the
legacy provider and are not available by default.

> Has the "classification" of ciphers changed?
> I didn't see anything obvious in CHANGES.

This may just be the "legacy provider" bit -- the SEED ciphers are
still listed as "MEDIUM" in the code (and there are some others that
are gated behind ssl-weak-ciphers).

-Ben

From matt at openssl.org  Thu Jun  4 07:59:10 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 4 Jun 2020 08:59:10 +0100
Subject: 3.0.0-alpha2: openssl ciphers MEDIUM empty?
In-Reply-To: <20200603233955.GV3811@akamai.com>
References: <20200603170532.GA47785@kiel.esmtp.org>
 <20200603233955.GV3811@akamai.com>
Message-ID: <47e53dba-0712-48d4-06c6-2871e7e894f2@openssl.org>



On 04/06/2020 00:39, Benjamin Kaduk via openssl-users wrote:
> only reports the TLS 1.3 ciphersuites and some SEED ciphers for an
> input of MEDIUM, and IIRC the SEED ciphers have been foisted off to the
> legacy provider and are not available by default.

Yes - this is exactly the reason. Explicitly loading the legacy and
default providers restores the previous behaviour:

$ openssl ciphers -provider legacy -provider default MEDIUM

TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA


Matt

From openssl at openssl.org  Thu Jun  4 14:32:20 2020
From: openssl at openssl.org (OpenSSL)
Date: Thu, 4 Jun 2020 14:32:20 +0000
Subject: OpenSSL version 3.0.0-alpha3 published
Message-ID: <20200604143220.GA30351@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 3.0 alpha 3 released
   ====================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in alpha.

   OpenSSL 3.0 alpha 3 has now been made available.

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
   as known issues are available on the OpenSSL Wiki, here:

        https://wiki.openssl.org/index.php/OpenSSL_3.0

   The alpha release is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-3.0.0-alpha3.tar.gz
      Size: 9622261
      SHA1 checksum:  4e5856fb85b1383d309d38874795043a787891ea
      SHA256 checksum:  354f25ff6c7ed90271e2f0718054ecab253cc4252942aa0e89b265e2795ae040

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.0.0-alpha3.tar.gz
    openssl sha256 openssl-3.0.0-alpha3.tar.gz

   Please download and check this alpha release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl7Y/ZwACgkQ2cTSbQ5g
RJH5+QgAi8M5sH+m8xnDTV+i9NFc9EAyzs1NMVY2B1/Yhzn+tSbKfR9tocKjFEB/
RV3cAjB1RBHtMxK9sI+O4PyE7Bkk81JB64RjAawY3Dy1kETWEJsulnzgkrpKtrM2
FbyCubL2sZgFevWVB4fDbUIr983o9Dg7idZehvq0zvVzg++bKm6edDDTaIBgisA3
gr+rA00bD++bddmqG7vm31HhN2/fYa+g719trXdfIcsyHhY+bsFtFqMOnO1D0N6f
d6dWBNIP8SjuYQ8GJPdPU+Ryro8uJpIUd1DlP7xDg1y21vUoWrzIStbUTIeZh+51
0Qy2tWa52xSBgYQN3tu11MN17rLEPQ==
=w062
-----END PGP SIGNATURE-----

From jhb at FreeBSD.org  Thu Jun  4 16:00:08 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Thu, 4 Jun 2020 09:00:08 -0700
Subject: How to help with getting KTLS patches merged
Message-ID: <cd2afa2d-213c-ab56-a4d2-8cc7d79085df@FreeBSD.org>

At the moment there are 3 open PRs related to Kernel TLS offload
support that I'm aware of:

- 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell
- 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will
  need to be rebased on top of 11589 once it is merged
- 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict
  a bit with 11589

Matt has already approved 11589, and I think 11589 looks ok from
my vantage point (I'm more familiar with the KTLS infrastructure
in FreeBSD rather than Linux).  Given that 11589 has received the
most review, I think it is probably prudent for it to be merged
first at for me to then rebase the other two PRs on top of that
and resolve conflicts, etc.

Is there anything I can do to help with getting 11589 merged?  I'm
not an OpenSSL committer, so I can't formally add the second
approval it needs.  Similarly once 11589 lands, is there anything
I can do to help get review on the other two PRs once they are
updated?

Ideally I'd really like to have these three merged into 3.0 before
it is released.  I'm already maintaining a side branch of 1.1.1
with KTLS support for use in FreeBSD's ports tree, but it would be
really nice if 3.0 did not require additional patches out of the
box.

Thanks!

-- 
John Baldwin

From nemokingdom at gmail.com  Fri Jun  5 01:04:47 2020
From: nemokingdom at gmail.com (Feng LI)
Date: Thu, 4 Jun 2020 18:04:47 -0700
Subject: [openssl][uwp] SSL_CTX_load_verify_locations not working for UWP port
Message-ID: <CAPekQOqv60ffnEH=JjW6=NMLVf=sGkKbitv8MAfsvCPaDyM4gw@mail.gmail.com>

SSL_CTX_load_verify_locations
<https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html>
is
required for UWP port to load ca file since OpenSSL will not use the CA of
the OS.

But in UWP build, stdio is disabled
<https://github.com/openssl/openssl/blob/082c041b4233b17b80129d4ac6b33a28014442b0/Configurations/50-win-onecore.conf#L113>
by
default. However, SSL_CTX_load_verify_locations relies on the default
X509_STORE file lookup functionality uses stdio (via BIO_s_file). That
basically means no verification of peers and hosts is possible with OpenSSL
on UWP port.

Is there a way to fix this or if there's a workaround for UWP ?


Thanks,
Feng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200604/1f89bddf/attachment.html>

From matt at openssl.org  Fri Jun  5 08:21:36 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 5 Jun 2020 09:21:36 +0100
Subject: [openssl][uwp] SSL_CTX_load_verify_locations not working for UWP
 port
In-Reply-To: <CAPekQOqv60ffnEH=JjW6=NMLVf=sGkKbitv8MAfsvCPaDyM4gw@mail.gmail.com>
References: <CAPekQOqv60ffnEH=JjW6=NMLVf=sGkKbitv8MAfsvCPaDyM4gw@mail.gmail.com>
Message-ID: <a571f2d1-06e6-b06a-f63c-ccd8ed09fca9@openssl.org>



On 05/06/2020 02:04, Feng LI wrote:
> SSL_CTX_load_verify_locations
> <https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html>?is
> required for UWP port to load ca file since OpenSSL will not use the CA
> of the OS.
> 
> But in UWP build,?stdio is disabled
> <https://github.com/openssl/openssl/blob/082c041b4233b17b80129d4ac6b33a28014442b0/Configurations/50-win-onecore.conf#L113>?by
> default. However, SSL_CTX_load_verify_locations relies on the default
> X509_STORE file lookup functionality uses stdio (via BIO_s_file). That
> basically means no verification of peers and hosts is possible with
> OpenSSL on UWP port.
> 
> Is there a way to fix this or if there's a workaround for UWP ?

If you can't use the file or dir lookup capabilities then you will have
to lookup certs/crls in some other way. There are two possible options
that spring to mind:

1) Implement a custom OSSL_STORE_LOADER (this is probably only viable
for OpenSSL 3.0)

You can implement a custom OSSL_STORE_LOADER via OSSL_STORE_LOADER_new

https://www.openssl.org/docs/manmaster/man3/OSSL_STORE_LOADER_new.html

You will then need to implement the various functions to find and load
the required CA certificates. Perhaps Richard Levitte might comment on
how to do that.

Once you have a custom OSSL_STORE_LOADER you will need to register it
via OSSL_STORE_register_loader() (also documented on the same man page
above).

Finally, you can set your SSL_CTX to use the store via
SSL_CTX_load_verify_store():

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_load_verify_store.html


2) Implement a custom X509_LOOKUP_METHOD

The file and dir lookup methods that SSL_CTX_load_verify_locations uses
are just the built-in ones. It's entirely possible to create your own.
Creating a custom X509_LOOKUP_METHOD involves creating the method via a
call to X509_LOOKUP_meth_new(). You will then need to additionally set
functions to get certs/crls via the different mechanisms, e.g.
X509_LOOKUP_meth_set_get_by_subject(),
X509_LOOKUP_meth_set_get_by_issuer_serial(),
X509_LOOKUP_meth_set_get_by_fingerprint(),
X509_LOOKUP_meth_set_get_by_alias().

Probably you can get away with just implementing the "get_by_subject"
function as a minimal set. The X509_LOOKUP_METHOD functions are
documented here:

https://www.openssl.org/docs/manmaster/man3/X509_LOOKUP_meth_new.html

Once you have a custom X509_LOOKUP_METHOD then you can add it to your
X509_STORE via X509_STORE_add_lookup():

https://www.openssl.org/docs/manmaster/man3/X509_STORE_add_lookup.html

To get the X509_STORE associated with your SSL_CTX you can use
SSL_CTX_get_cert_store():

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_cert_store.html

Hope, that helps.

Matt



From levitte at openssl.org  Fri Jun  5 09:43:07 2020
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 05 Jun 2020 11:43:07 +0200
Subject: [openssl][uwp] SSL_CTX_load_verify_locations not working for UWP
 port
In-Reply-To: <CAPekQOqv60ffnEH=JjW6=NMLVf=sGkKbitv8MAfsvCPaDyM4gw@mail.gmail.com>
References: <CAPekQOqv60ffnEH=JjW6=NMLVf=sGkKbitv8MAfsvCPaDyM4gw@mail.gmail.com>
Message-ID: <87wo4lrgpg.wl-levitte@openssl.org>

On Fri, 05 Jun 2020 03:04:47 +0200,
Feng LI wrote:
> SSL_CTX_load_verify_locations?is required for UWP port to load ca file since OpenSSL will not use
> the CA of the OS.
> 
> But in UWP build,?stdio is disabled?by default. However, SSL_CTX_load_verify_locations relies on
> the default X509_STORE file lookup functionality uses stdio (via BIO_s_file). That basically means
> no verification of peers and hosts is possible with OpenSSL on UWP port.
> 
> Is there a way to fix this or if there's a workaround for UWP ?

It should be enough to use BIO_s_fd() instead of BIO_s_file() (it
takes a bit more than a mere change of function name, OpenSSL's file
descriptor isn't quite designed for use with files, unfortunately).

That is, with the assumption that POSIX file descriptors can be used
at all with UWP...  otherwise, someone will have to come up with a BIO
method that supports whatever file API that UWP supports.

Cheers,
Richard

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

From angus at magsys.co.uk  Fri Jun  5 12:03:00 2020
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Fri, 5 Jun 2020 13:03 +0100 (BST)
Subject: Cleanup of the EC API
Message-ID: <memo.20200605130310.12032A@magsys.adsl.magsys.co.uk>

If possible, a EC_KEY_get_public_key_affine_coordinates function would
be appreciated, so we can avoid using
EC_POINT_get_affine_coordinates_GFp. Unless I've missed a better
function to get raw x/y. 

Perhaps also EC_KEY_get_curve_name?  

Angus


From john.sha.jiang at gmail.com  Sun Jun  7 10:58:03 2020
From: john.sha.jiang at gmail.com (John Jiang)
Date: Sun, 7 Jun 2020 18:58:03 +0800
Subject: Specify multiple certs for s_server and s_client
Message-ID: <CAJbO6CR9cEQuRBT_aq3zdrpkaKZ39QA9TiHH3dj+qObkEgzUKA@mail.gmail.com>

Hi,
Can I specify multiple certificates for tools s_server and s_client?
I need to check the certificate selection with certificate_authorities.

And it looks s_server has no option for certificate_authorities, however
s_client has -requestCAfile for that extension.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200607/5a992db4/attachment.html>

From mcr at sandelman.ca  Mon Jun  8 01:45:55 2020
From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 07 Jun 2020 21:45:55 -0400
Subject: Specify multiple certs for s_server and s_client
In-Reply-To: <CAJbO6CR9cEQuRBT_aq3zdrpkaKZ39QA9TiHH3dj+qObkEgzUKA@mail.gmail.com>
References: <CAJbO6CR9cEQuRBT_aq3zdrpkaKZ39QA9TiHH3dj+qObkEgzUKA@mail.gmail.com>
Message-ID: <14699.1591580755@localhost>

John Jiang <john.sha.jiang at gmail.com> wrote:
    > Hi, Can I specify multiple certificates for tools s_server and
    > s_client?  I need to check the certificate selection with
    > certificate_authorities.

    > And it looks s_server has no option for certificate_authorities,
    > however s_client has -requestCAfile for that extension.

I believe that s_client and s_server are really intended as testing tools,
and if you are getting into more complex situations, you should copy
the example, simplify it, and then instrument the callbacks to do
the certificate checking that you need.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


From kurt at roeckx.be  Mon Jun  8 11:12:33 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 8 Jun 2020 13:12:33 +0200
Subject: How to help with getting KTLS patches merged
In-Reply-To: <cd2afa2d-213c-ab56-a4d2-8cc7d79085df@FreeBSD.org>
References: <cd2afa2d-213c-ab56-a4d2-8cc7d79085df@FreeBSD.org>
Message-ID: <20200608111233.GA716779@roeckx.be>

On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote:
> At the moment there are 3 open PRs related to Kernel TLS offload
> support that I'm aware of:
> 
> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell
> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will
>   need to be rebased on top of 11589 once it is merged
> - 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict
>   a bit with 11589
> 
> Matt has already approved 11589, and I think 11589 looks ok from
> my vantage point (I'm more familiar with the KTLS infrastructure
> in FreeBSD rather than Linux).  Given that 11589 has received the
> most review, I think it is probably prudent for it to be merged
> first at for me to then rebase the other two PRs on top of that
> and resolve conflicts, etc.

11589 has now been merged.


Kurt


From np at acronisscs.com  Mon Jun  8 18:53:32 2020
From: np at acronisscs.com (Neil Proctor)
Date: Mon, 8 Jun 2020 18:53:32 +0000
Subject: Are there any flag that control client finished hash verification
Message-ID: <CY4PR07MB29203C823BDFCC6EF8A3D05FA3850@CY4PR07MB2920.namprd07.prod.outlook.com>

Hello,

Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake finished hash is verified by the server?  Or is this always performed regardless of configuration?

During some of our testing, it seems that even if the last byte of the client handshake finished hash gets modified, the server will still accept and complete the handshake and the TLS connection.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200608/f531779e/attachment.html>

From bkaduk at akamai.com  Mon Jun  8 20:29:22 2020
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 8 Jun 2020 13:29:22 -0700
Subject: Are there any flag that control client finished hash verification
In-Reply-To: <CY4PR07MB29203C823BDFCC6EF8A3D05FA3850@CY4PR07MB2920.namprd07.prod.outlook.com>
References: <CY4PR07MB29203C823BDFCC6EF8A3D05FA3850@CY4PR07MB2920.namprd07.prod.outlook.com>
Message-ID: <20200608202922.GA3811@akamai.com>

On Mon, Jun 08, 2020 at 06:53:32PM +0000, Neil Proctor via openssl-users wrote:
> Hello,
> 
> Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake finished hash is verified by the server?  Or is this always performed regardless of configuration?
> 
> During some of our testing, it seems that even if the last byte of the client handshake finished hash gets modified, the server will still accept and complete the handshake and the TLS connection.

Full validation of the Finished is supposed to be done always.
Please try to write up some discussion of your test cases; probably a github
issue is best (though mail to this list is okay too).

Thanks,

Ben

From sri.deep07 at gmail.com  Mon Jun  8 23:01:37 2020
From: sri.deep07 at gmail.com (Anand Sridharan)
Date: Mon, 8 Jun 2020 16:01:37 -0700
Subject: Extension of certificate expiry date
Message-ID: <CAPC6fefFOa=P8qRH9bGwPZ6WgXhiOHRWrmCms4-kVfamNujr+g@mail.gmail.com>

Hi openssl users,

is there a way on openssl to extend the expiry of certificate date?

I created a certificate with an expiry date set for 365 days but looking
now to extend it longer or indefinitely.
-- 
thanks,

Anand.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200608/ba44faf3/attachment.html>

From openssl-users at dukhovni.org  Mon Jun  8 23:15:48 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 8 Jun 2020 19:15:48 -0400
Subject: Extension of certificate expiry date
In-Reply-To: <CAPC6fefFOa=P8qRH9bGwPZ6WgXhiOHRWrmCms4-kVfamNujr+g@mail.gmail.com>
References: <CAPC6fefFOa=P8qRH9bGwPZ6WgXhiOHRWrmCms4-kVfamNujr+g@mail.gmail.com>
Message-ID: <20200608231548.GT48101@straasha.imrryr.org>

On Mon, Jun 08, 2020 at 04:01:37PM -0700, Anand Sridharan wrote:

> is there a way on openssl to extend the expiry of certificate date?
> 
> I created a certificate with an expiry date set for 365 days but looking
> now to extend it longer or indefinitely.

You need to sign a new certificate for the same subject name and public
key.  While it is possible to use an existing certificate as a
"template" the new certificate, it is often simpler to just create a new
one.  Is there any reason why that's not a good option for you?

-- 
    Viktor.

From sri.deep07 at gmail.com  Tue Jun  9 02:43:46 2020
From: sri.deep07 at gmail.com (Anand Sridharan)
Date: Mon, 8 Jun 2020 19:43:46 -0700
Subject: Extension of certificate expiry date
In-Reply-To: <20200608231548.GT48101@straasha.imrryr.org>
References: <CAPC6fefFOa=P8qRH9bGwPZ6WgXhiOHRWrmCms4-kVfamNujr+g@mail.gmail.com>
 <20200608231548.GT48101@straasha.imrryr.org>
Message-ID: <CAPC6feeVsV4fU5v43VEpNQX_FN-VWLa0+WVmm=FB5iioK0jnFQ@mail.gmail.com>

Hi Viktor ,
we have used hardcoded certificate information in a piece of code , we
don't want to change it often.
There aren't any other reasons for it.

On Mon, Jun 8, 2020 at 4:21 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Mon, Jun 08, 2020 at 04:01:37PM -0700, Anand Sridharan wrote:
>
> > is there a way on openssl to extend the expiry of certificate date?
> >
> > I created a certificate with an expiry date set for 365 days but looking
> > now to extend it longer or indefinitely.
>
> You need to sign a new certificate for the same subject name and public
> key.  While it is possible to use an existing certificate as a
> "template" the new certificate, it is often simpler to just create a new
> one.  Is there any reason why that's not a good option for you?
>
> --
>     Viktor.
>


-- 
thanks,

Anand.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200608/d3e16fc8/attachment.html>

From openssl-users at dukhovni.org  Tue Jun  9 03:41:54 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 8 Jun 2020 23:41:54 -0400
Subject: Extension of certificate expiry date
In-Reply-To: <CAPC6feeVsV4fU5v43VEpNQX_FN-VWLa0+WVmm=FB5iioK0jnFQ@mail.gmail.com>
References: <CAPC6fefFOa=P8qRH9bGwPZ6WgXhiOHRWrmCms4-kVfamNujr+g@mail.gmail.com>
 <20200608231548.GT48101@straasha.imrryr.org>
 <CAPC6feeVsV4fU5v43VEpNQX_FN-VWLa0+WVmm=FB5iioK0jnFQ@mail.gmail.com>
Message-ID: <20200609034154.GU48101@straasha.imrryr.org>

On Mon, Jun 08, 2020 at 07:43:46PM -0700, Anand Sridharan wrote:

> We have used hardcoded certificate information in a piece of code , we
> don't want to change it often.  There aren't any other reasons for it.

Just generate a new certificate, you can use the same key if you like.

-- 
    Viktor.

From vkaliape at gmail.com  Tue Jun  9 08:55:10 2020
From: vkaliape at gmail.com (Vijayakumar Kaliaperumal)
Date: Tue, 9 Jun 2020 14:25:10 +0530
Subject: DTLS Heartbeat Removed in OpenSSL 1.1.1
Message-ID: <CADNrMSJ6BkOq=eb8QBcOKQJ3q4ZtrTn9KaoK5aP6L4_ws8GoVw@mail.gmail.com>

Hello,

>From the release notes of OpenSSL 1.1.1, I could see that DTLS heartbeat
has been removed
.
Heartbeat support has been removed; the ABI is changed for now.

With  RFC 6520 in standards track, any specific reason(Vulnerability/other
security issue reported) for the removal ?,   How can we re-enable it ?
Recompile OpenSSL without OPENSSL_NO_HEARTBEATS macro ?   Please advise.

Regards,
Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200609/3b20cd62/attachment.html>

From stanermetin at gmail.com  Tue Jun  9 09:18:01 2020
From: stanermetin at gmail.com (Taner)
Date: Tue, 9 Jun 2020 11:18:01 +0200
Subject: Cancellation
Message-ID: <CAGdqjjHV96+nUzXoTvM5AC4V6OWT359wU7CeqougtOg9ATgk-w@mail.gmail.com>

Hello,

I would like to leave the mailing list. and could not do myself.  could you
remove me from your mailing list?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200609/3b326a10/attachment-0001.html>

From mlev.mail at gmail.com  Tue Jun  9 09:26:20 2020
From: mlev.mail at gmail.com (=?UTF-8?B?TWljaGFlbCBMZXYg157Xmdeb15DXnCDXnNeQ15E=?=)
Date: Tue, 9 Jun 2020 12:26:20 +0300
Subject: installing openssl on win10 64bit
Message-ID: <CAKm5fWj-CevL7-xuYTMgdLF-MnC+KsJ4m+aPs0HYj7PO7AZvfA@mail.gmail.com>

Hi,
For developing and testing I need http server on my win10 64 bit pc,
so I use http server from
https://www.npmjs.com/package/http-server
<https://mailtrack.io/trace/link/a1830b0b3afe9696c68d7f27720e675272ae92d6?url=https%3A%2F%2Fwww.npmjs.com%2Fpackage%2Fhttp-server&userId=1218955&signature=020f40c6ee26fbc6>


Sometimes I get and err msg saying:

This site can?t provide a secure connectionmlev-pc-hp sent an invalid
response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR


I understand that I need to install openSsl from
https://github.com/openssl/openssl
<https://mailtrack.io/trace/link/1eb88d61540ef30a080bcfbb9b5b4190c18f7ead?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl&userId=1218955&signature=aaa910ea35905673>


but I am not an expert enough to know what to do.
The INSTALL file does not elaborate enough to tell me step by step what to
do.

I'll appreciate getting help.
Michael

*????? ??? - **Michael Lev*

054-7718425
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200609/ec02e58c/attachment.html>

From matt at openssl.org  Tue Jun  9 11:43:18 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 9 Jun 2020 12:43:18 +0100
Subject: installing openssl on win10 64bit
In-Reply-To: <CAKm5fWj-CevL7-xuYTMgdLF-MnC+KsJ4m+aPs0HYj7PO7AZvfA@mail.gmail.com>
References: <CAKm5fWj-CevL7-xuYTMgdLF-MnC+KsJ4m+aPs0HYj7PO7AZvfA@mail.gmail.com>
Message-ID: <4f637061-81ca-146d-be8c-8e8e0957d22c@openssl.org>



On 09/06/2020 10:26, Michael Lev ????? ??? wrote:
> Hi,
> For developing and testing I need http server on my win10 64 bit pc,
> so I use http server from?
> https://www.npmjs.com/package/http-server
> <https://mailtrack.io/trace/link/a1830b0b3afe9696c68d7f27720e675272ae92d6?url=https%3A%2F%2Fwww.npmjs.com%2Fpackage%2Fhttp-server&userId=1218955&signature=020f40c6ee26fbc6>??
> ?
> Sometimes?I get and err msg saying:
> 
>     This site can?t provide a secure connectionmlev-pc-hp sent an
>     invalid response.
>     Try running Windows Network Diagnostics.
>     ERR_SSL_PROTOCOL_ERROR
> 
> 
> I understand that I need to install openSsl from?
> https://github.com/openssl/openssl
> <https://mailtrack.io/trace/link/1eb88d61540ef30a080bcfbb9b5b4190c18f7ead?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl&userId=1218955&signature=aaa910ea35905673>?
> 
> but I am not an expert enough to know what to do.
> The INSTALL file does not elaborate enough to tell me step by step what
> to do.

You might want to install a precompiled binary instead. The project
doesn't produce these, but a number of third parties do. We maintain a
list of them here:

https://wiki.openssl.org/index.php/Binaries

Matt


From paul.davis at curatess.com  Tue Jun  9 14:17:29 2020
From: paul.davis at curatess.com (Paul)
Date: Tue, 9 Jun 2020 09:17:29 -0500
Subject: Cancel of mailing list
Message-ID: <CAAf=oSpwm3AigpHgK7KoiY6O0VhPLuyzmPpFH++w6gLsZb1qLw@mail.gmail.com>

Can you please remove my email from mailing list?

-- 
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200609/36b5fdd4/attachment.html>

From thiyaneshece at gmail.com  Tue Jun  9 15:22:31 2020
From: thiyaneshece at gmail.com (THIYANESWARAN)
Date: Tue, 9 Jun 2020 20:52:31 +0530
Subject: PSK and NULL ciphers availability
Message-ID: <CAHMs9Dk=a2Wf9XbL4RNyCi_DU4Wo182QpC9zLcV0M=c-cq0oxg@mail.gmail.com>

*Requirement : * The cipher suites(PSK-AES128-GCM-SHA256  and PSK-NULL-SHA256)
are needed to be set during the handshake process between client and server
in python(3.7) testframe using standard library ssl module(wrapper for
openssl). My understanding is that PSK and weak ciphers are not enabled by
default  in openssl. *Is my understanding correct? or these ciphers
available by default?*

*so in case,if it is available, how can i set the ciphers and the project
wants to use TLSv1.2 protocol.*
*Openssl version - *OpenSSL 1.1.0j  20 Nov 2018

Thanks and Regards,
Dinesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200609/8b1019c1/attachment.html>

From warron.french at gmail.com  Tue Jun  9 20:14:21 2020
From: warron.french at gmail.com (warron.french)
Date: Tue, 9 Jun 2020 16:14:21 -0400
Subject: Cancel of mailing list
In-Reply-To: <CAAf=oSpwm3AigpHgK7KoiY6O0VhPLuyzmPpFH++w6gLsZb1qLw@mail.gmail.com>
References: <CAAf=oSpwm3AigpHgK7KoiY6O0VhPLuyzmPpFH++w6gLsZb1qLw@mail.gmail.com>
Message-ID: <CAJdJdQ=QjsxNH5x2vJO_uOoBG7AiOQTe1YnaZaePYuYMhN=QMg@mail.gmail.com>

I believe you need to refer to this link:-
https://mta.openssl.org/pipermail/openssl-users/2016-July/003979.html
There are two options for you with which you can remove yourself Paul.

Good luck,
--------------------------
Warron French



On Tue, Jun 9, 2020 at 10:18 AM Paul <paul.davis at curatess.com> wrote:

> Can you please remove my email from mailing list?
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200609/410a198b/attachment.html>

From jhb at FreeBSD.org  Wed Jun 10 22:48:57 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Wed, 10 Jun 2020 15:48:57 -0700
Subject: How to help with getting KTLS patches merged
In-Reply-To: <20200608111233.GA716779@roeckx.be>
References: <cd2afa2d-213c-ab56-a4d2-8cc7d79085df@FreeBSD.org>
 <20200608111233.GA716779@roeckx.be>
Message-ID: <a4d8528b-e0cd-7f7f-8011-8753730da4a5@FreeBSD.org>

On 6/8/20 4:12 AM, Kurt Roeckx wrote:
> On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote:
>> At the moment there are 3 open PRs related to Kernel TLS offload
>> support that I'm aware of:
>>
>> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell
>> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will
>>   need to be rebased on top of 11589 once it is merged
>> - 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict
>>   a bit with 11589
>>
>> Matt has already approved 11589, and I think 11589 looks ok from
>> my vantage point (I'm more familiar with the KTLS infrastructure
>> in FreeBSD rather than Linux).  Given that 11589 has received the
>> most review, I think it is probably prudent for it to be merged
>> first at for me to then rebase the other two PRs on top of that
>> and resolve conflicts, etc.
> 
> 11589 has now been merged.

Thanks for all the folks who jumped in to review that!

-- 
John Baldwin

From hmurray at megapathdsl.net  Thu Jun 11 00:49:04 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 10 Jun 2020 17:49:04 -0700
Subject: Cleaning up usage of CMAC_xxx
Message-ID: <20200611004904.C55D940605C@ip-64-139-1-69.sjc.megapath.net>


CMAC_* have been DEPRECATED for 3.0.0

CHANGES.md suggests using EVP_MAC_xxx.  Mostly, that seems reasonable, but 
there is one loose end.

CMAC_Init includes a key and cipher.  What's the equivalent in EVP_MAC_xxx?

-----------

I found the params stuff, but that's new in 3.0.0
How do I do it in 1.1.1 or earlier?



-- 
These are my opinions.  I hate spam.




From levitte at openssl.org  Thu Jun 11 08:12:32 2020
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 11 Jun 2020 10:12:32 +0200
Subject: Cleaning up usage of CMAC_xxx
In-Reply-To: <20200611004904.C55D940605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200611004904.C55D940605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <87a71aowb3.wl-levitte@openssl.org>

On Thu, 11 Jun 2020 02:49:04 +0200,
Hal Murray wrote:
> CMAC_* have been DEPRECATED for 3.0.0
> 
> CHANGES.md suggests using EVP_MAC_xxx.  Mostly, that seems reasonable, but 
> there is one loose end.
> 
> CMAC_Init includes a key and cipher.  What's the equivalent in EVP_MAC_xxx?
> 
> -----------
> 
> I found the params stuff, but that's new in 3.0.0
> How do I do it in 1.1.1 or earlier?

In 1.1.1 and earlier, there is a different idea, using EVP_PKEY
routines to "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge
in 3.0.0 to bridge the gap.

Cheers,
Richard

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

From hmurray at megapathdsl.net  Thu Jun 11 23:27:26 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 11 Jun 2020 16:27:26 -0700
Subject: Cleaning up usage of CMAC_xxx
In-Reply-To: Message from Richard Levitte <levitte@openssl.org>
 of "Thu, 11 Jun 2020 10:12:32 +0200." <87a71aowb3.wl-levitte@openssl.org>
Message-ID: <20200611232726.16F4640605C@ip-64-139-1-69.sjc.megapath.net>


levitte at openssl.org said:
> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to
> "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge
> the gap. 

Thanks, but...

The EVP_PKEY seems to assume a public/private key environment.  The man page 
for EVP_PKEY_new() says:
       The structure returned by EVP_PKEY_new() is empty. To add a private or
       public key to this empty structure use the appropriate functions
       described in EVP_PKEY_set1_RSA(3), EVP_PKEY_set1_DSA, EVP_PKEY_set1_DH
       or EVP_PKEY_set1_EC_KEY.

We don't have public/private keys.  Perhaps it will help if I describe our 
environment.

The context is NTP.  NTP is a classic client/server, request/response 
protocol.  It uses UDP which is easily forged.  Basic packets are 48 bytes.

Shared-key authentication is optional.  Out of band, the client and server 
agree on a key, algorithm, and key ID.  The ID is an index into a (hash?) 
table of algorithm and key.  Authenticated packets have the ID and MAC 
appended to the packet.  The length of the MAC depends on the algorithm.

Key info comes from the keyboard or a text file with 1 line per key.  NIST 
uses USPS to distribute keys.

Busy servers process 10K-100K packets per second.  On the server, each packet 
requires 2 passes through the MAC algorithm, one to verify the MAC when 
receiving a request and another to compute the MAC when sending the response.  
The NTP protocol is simple.  The MAC calculations are a significant fraction 
of the per packet CPU load.  I'd like a fast/clean API to the low level MAC 
routines.  The CMAC API was good.

---------

I'm willing to do a reasonable amount of setup work during initialization, for 
example turning "AES" from a file to a EVP_CIPHER* to feed to CMAC_Init()  
Clean is more important than fast.

I'm willing to have totally separate implementations for 3.0.0 and 1.x.x if 
that's the cleanest way to go.

I'm slightly concerned that the params API will be slow.  It's moving string 
lookups into the mainline.  I don't have any numbers yet.

---------

We also have a similar HMAC like digest mode using MD5 and SHA1 via 
EVP_Digest.  Will that API be around long term?


-- 
These are my opinions.  I hate spam.




From matrixwxz at gmail.com  Fri Jun 12 04:01:53 2020
From: matrixwxz at gmail.com (Xinzhe Wang)
Date: Fri, 12 Jun 2020 12:01:53 +0800
Subject: Probably memory leak on handshake when KTLS enabled
Message-ID: <CAAUWc4pV0pQ-iL2Jn3Kw=wvEUbky5i2w9EmKiUfQ3tdnA1To4g@mail.gmail.com>

When KTLS is enabled, multiple client's handshake will lead to unexpected
eof while reading and data corrupt(possible memory leak).

Tested OpenSSL version: master, 3.0.0-alpha1
Kernel version: 5.4.43-1-MANJARO
Reproduce step(using docker):

sudo modprobe tls
git clone https://github.com/openssl/openssl.git
sudo docker run -it -v $(pwd)/openssl:/openssl archlinux

# [In docker]
pacman -Sy make gcc vim
cd openssl
./config enable-ktls
make build_sw -j4
pacman -Rdd openssl
make install_sw

cd /
vim server.cpp
# https://paste.ubuntu.com/p/fyhr6dDR7G/
vim client.cpp
# https://paste.ubuntu.com/p/P2DjwWhTkf/
vim server.pem
# https://paste.ubuntu.com/p/QttnVGsVSm/
vim serverkey.pem
# https://paste.ubuntu.com/p/g6QR84wSfw/

g++ -c -o client.o client.cpp
g++ -o client client.o -lssl -lcrypto
g++ -c -o server.o server.cpp
g++ -o server server.o -lssl -lcrypto
export LD_LIBRARY_PATH=/usr/local/lib
./server &
./client


You will see like this

FP
 Vtest test
test
test
Mljtest test
test
test
test
test
test
test
Error creating SSL connection.  err=ffffffff
error:14000126:SSL routines::unexpected eof while reading

When OpenSSL is compiled without ktls, the client will print test
infinitely, but when enable ktls, some data are corrupted and sometimes
result in unexpected eof while reading.

Even when you remove SSL_write(ssl, reply, strlen(reply)); in server and
RecvPacket(); in client, it will also result in unexpected eof while
reading so I think there is something wrong with handshake procedure when
ktls is enabled, maybe memory leak or UAF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200612/ecb6ca36/attachment.html>

From matt at openssl.org  Fri Jun 12 08:25:17 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2020 09:25:17 +0100
Subject: Cleaning up usage of CMAC_xxx
In-Reply-To: <20200611232726.16F4640605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200611232726.16F4640605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <73522e34-a936-24ec-4cf5-f52812549ca2@openssl.org>



On 12/06/2020 00:27, Hal Murray wrote:
> 
> levitte at openssl.org said:
>> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to
>> "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge
>> the gap. 
> 
> Thanks, but...
> 
> The EVP_PKEY seems to assume a public/private key environment.  The man page 
> for EVP_PKEY_new() says:

Nonetheless, what Richard says is correct. You can still do MAC
operations using EVP_PKEY. Its a horrible hack, and that's why we
introduced the EVP_MAC interface instead.

There's is some content on the Wiki about how to do HMAC using the "old"
EVP_PKEY approach. The same thing should also apply to CMAC:

https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying#HMAC

You can create an EVP_PKEY with an HMAC key using the function
EVP_PKEY_new_raw_private_key() and a CMAC key using the function
EVP_PKEY_new_CMAC_key():

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_new_CMAC_key.html

However, EVP_MAC is the way of the future and should be the preferred
approach for anything running in 3.0 or above.

> I'm willing to have totally separate implementations for 3.0.0 and 1.x.x if 
> that's the cleanest way to go.

If you can afford the additional complexity, then I think it is worth it
- but its not strictly necessary (the old EVP_PKEY method does still
work in 3.0).

> I'm slightly concerned that the params API will be slow.  It's moving string 
> lookups into the mainline.  I don't have any numbers yet.

We don't expect it to be significantly worse - but we'd be very
interested in any numbers that you are able to produce.

> We also have a similar HMAC like digest mode using MD5 and SHA1 via 
> EVP_Digest.  Will that API be around long term?

We expect EVP_Digest* to be around for the long term.

Matt

From beldmit at gmail.com  Fri Jun 12 10:23:56 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 12 Jun 2020 13:23:56 +0300
Subject: Probably memory leak on handshake when KTLS enabled
In-Reply-To: <CAAUWc4pV0pQ-iL2Jn3Kw=wvEUbky5i2w9EmKiUfQ3tdnA1To4g@mail.gmail.com>
References: <CAAUWc4pV0pQ-iL2Jn3Kw=wvEUbky5i2w9EmKiUfQ3tdnA1To4g@mail.gmail.com>
Message-ID: <CADqLbzJEEviPOMi36RFx3CwYp6H+A_Aiog2Of6AZQXMVcT+97Q@mail.gmail.com>

Could you please try to re-run the client via Valgrind?

On Fri, Jun 12, 2020 at 7:03 AM Xinzhe Wang <matrixwxz at gmail.com> wrote:

> When KTLS is enabled, multiple client's handshake will lead to unexpected
> eof while reading and data corrupt(possible memory leak).
>
> Tested OpenSSL version: master, 3.0.0-alpha1
> Kernel version: 5.4.43-1-MANJARO
> Reproduce step(using docker):
>
> sudo modprobe tls
> git clone https://github.com/openssl/openssl.git
> sudo docker run -it -v $(pwd)/openssl:/openssl archlinux
>
> # [In docker]
> pacman -Sy make gcc vim
> cd openssl
> ./config enable-ktls
> make build_sw -j4
> pacman -Rdd openssl
> make install_sw
>
> cd /
> vim server.cpp
> # https://paste.ubuntu.com/p/fyhr6dDR7G/
> vim client.cpp
> # https://paste.ubuntu.com/p/P2DjwWhTkf/
> vim server.pem
> # https://paste.ubuntu.com/p/QttnVGsVSm/
> vim serverkey.pem
> # https://paste.ubuntu.com/p/g6QR84wSfw/
>
> g++ -c -o client.o client.cpp
> g++ -o client client.o -lssl -lcrypto
> g++ -c -o server.o server.cpp
> g++ -o server server.o -lssl -lcrypto
> export LD_LIBRARY_PATH=/usr/local/lib
> ./server &
> ./client
>
>
> You will see like this
>
> FP
>  Vtest test
> test
> test
> Mljtest test
> test
> test
> test
> test
> test
> test
> Error creating SSL connection.  err=ffffffff
> error:14000126:SSL routines::unexpected eof while reading
>
> When OpenSSL is compiled without ktls, the client will print test
> infinitely, but when enable ktls, some data are corrupted and sometimes
> result in unexpected eof while reading.
>
> Even when you remove SSL_write(ssl, reply, strlen(reply)); in server and
> RecvPacket(); in client, it will also result in unexpected eof while
> reading so I think there is something wrong with handshake procedure when
> ktls is enabled, maybe memory leak or UAF.
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200612/4d8e893b/attachment-0001.html>

From matrixwxz at gmail.com  Fri Jun 12 11:09:56 2020
From: matrixwxz at gmail.com (Xinzhe Wang)
Date: Fri, 12 Jun 2020 19:09:56 +0800
Subject: Probably memory leak on handshake when KTLS enabled
In-Reply-To: <CADqLbzJEEviPOMi36RFx3CwYp6H+A_Aiog2Of6AZQXMVcT+97Q@mail.gmail.com>
References: <CAAUWc4pV0pQ-iL2Jn3Kw=wvEUbky5i2w9EmKiUfQ3tdnA1To4g@mail.gmail.com>
 <CADqLbzJEEviPOMi36RFx3CwYp6H+A_Aiog2Of6AZQXMVcT+97Q@mail.gmail.com>
Message-ID: <CAAUWc4or0P+7JKqE0=nJi7EQRwfCHLmPmO_9qc3e7ALOTuA7EA@mail.gmail.com>

$ valgrind --leak-check=full ./client
==18674== Memcheck, a memory error detector

==18674== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.

==18674== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright
info
==18674== Command: ./client

==18674==

ZS\!U??e;+UbH1XF

?Sj

    aETg[Y



          .Error creating SSL connection.  err=ffffffff

error:14000126:SSL routines::unexpected eof while reading

==18674==

==18674== HEAP SUMMARY:
==18674==     in use at exit: 942,770 bytes in 3,508 blocks
==18674==   total heap usage: 372,389 allocs, 368,881 frees, 116,999,626
bytes allocated
==18674==
==18674== 865,305 (159,600 direct, 705,705 indirect) bytes in 21 blocks are
definitel
y lost in loss record 222 of 222
==18674==    at 0x483977F: malloc (vg_replace_malloc.c:307)
==18674==    by 0x4AB7709: CRYPTO_zalloc (in /usr/local/lib/libcrypto.so.3)
==18674==    by 0x487F015: SSL_new (in /usr/local/lib/libssl.so.3)
==18674==    by 0x109597: main (in /client)
==18674==
==18674== LEAK SUMMARY:
==18674==    definitely lost: 159,600 bytes in 21 blocks
==18674==    indirectly lost: 705,705 bytes in 3,276 blocks
==18674==      possibly lost: 0 bytes in 0 blocks
==18674==    still reachable: 77,465 bytes in 211 blocks
==18674==         suppressed: 0 bytes in 0 blocks
==18674== Reachable blocks (those to which a pointer was found) are not
shown.
==18674== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==18674==
==18674== For lists of detected and suppressed errors, rerun with: -s
==18674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Dmitry Belyavsky <beldmit at gmail.com> ?2020?6?12??? ??6:24???

> Could you please try to re-run the client via Valgrind?
>
> On Fri, Jun 12, 2020 at 7:03 AM Xinzhe Wang <matrixwxz at gmail.com> wrote:
>
>> When KTLS is enabled, multiple client's handshake will lead to unexpected
>> eof while reading and data corrupt(possible memory leak).
>>
>> Tested OpenSSL version: master, 3.0.0-alpha1
>> Kernel version: 5.4.43-1-MANJARO
>> Reproduce step(using docker):
>>
>> sudo modprobe tls
>> git clone https://github.com/openssl/openssl.git
>> sudo docker run -it -v $(pwd)/openssl:/openssl archlinux
>>
>> # [In docker]
>> pacman -Sy make gcc vim
>> cd openssl
>> ./config enable-ktls
>> make build_sw -j4
>> pacman -Rdd openssl
>> make install_sw
>>
>> cd /
>> vim server.cpp
>> # https://paste.ubuntu.com/p/fyhr6dDR7G/
>> vim client.cpp
>> # https://paste.ubuntu.com/p/P2DjwWhTkf/
>> vim server.pem
>> # https://paste.ubuntu.com/p/QttnVGsVSm/
>> vim serverkey.pem
>> # https://paste.ubuntu.com/p/g6QR84wSfw/
>>
>> g++ -c -o client.o client.cpp
>> g++ -o client client.o -lssl -lcrypto
>> g++ -c -o server.o server.cpp
>> g++ -o server server.o -lssl -lcrypto
>> export LD_LIBRARY_PATH=/usr/local/lib
>> ./server &
>> ./client
>>
>>
>> You will see like this
>>
>> FP
>>  Vtest test
>> test
>> test
>> Mljtest test
>> test
>> test
>> test
>> test
>> test
>> test
>> Error creating SSL connection.  err=ffffffff
>> error:14000126:SSL routines::unexpected eof while reading
>>
>> When OpenSSL is compiled without ktls, the client will print test
>> infinitely, but when enable ktls, some data are corrupted and sometimes
>> result in unexpected eof while reading.
>>
>> Even when you remove SSL_write(ssl, reply, strlen(reply)); in server and
>> RecvPacket(); in client, it will also result in unexpected eof while
>> reading so I think there is something wrong with handshake procedure when
>> ktls is enabled, maybe memory leak or UAF.
>>
>
>
> --
> SY, Dmitry Belyavsky
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200612/34ec5f59/attachment.html>

From hmurray at megapathdsl.net  Fri Jun 12 20:41:53 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 12 Jun 2020 13:41:53 -0700
Subject: Cleaning up usage of CMAC_xxx
In-Reply-To: Message from Matt Caswell <matt@openssl.org> of "Fri,
 12 Jun 2020 09:25:17 BST." <73522e34-a936-24ec-4cf5-f52812549ca2@openssl.org>
Message-ID: <20200612204153.7159740605C@ip-64-139-1-69.sjc.megapath.net>

Thanks.

> and a CMAC key using the function EVP_PKEY_new_CMAC_key():

That's the step I was missing.  Right in front of my eyes.

I'm still missing something though.

Does this look reasonable: 
    cipher = EVP_aes_128_cbc();
    pkey = EVP_PKEY_new_CMAC_key(NULL, key, keylength, cipher);
    ctx = EVP_PKEY_CTX_new(pkey, NULL);
    EVP_PKEY_sign_init(ctx);
The last step dies with:
  error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not 
supported for this keytype.

[It will probably be obvious after somebody points me in the right direction.]

That cipher work with CMAC.


-- 
These are my opinions.  I hate spam.




From dheinz at softwarekey.com  Sat Jun 13 14:38:56 2020
From: dheinz at softwarekey.com (Dan Heinz)
Date: Sat, 13 Jun 2020 14:38:56 +0000
Subject: 64-bit 1.1.1e fails to build on macOS 10.8
Message-ID: <DM6PR06MB406003002CEEABEF4485E080D99E0@DM6PR06MB4060.namprd06.prod.outlook.com>

Hello,

I updated from 1.1.1d to the latest version 1.1.1g and had a build error on macOS 10.8 for the 64-bit crypto library.  I rolled back to 1.1.1e and reproduced the build error.
32-bit is building fine, only 64-bit has the issue.  I looked at the commits for 1.1.1e and nothing jumped out at me.

The config parameters are the same between the 64-bit and 32-bit builds other than specific parameters needed to specify the 64-bit build.
./Configure --config=../Patches/openssl/custom_config.conf $os_compiler --prefix=$install_path/openssl_64 -DPURIFY -DOPENSSL_NO_COMP no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared no-threads


Here is the bottom of the output from the build where the error occurs.  It seems like cryptlib.h is not being included for some reason?


cc  -I. -Iinclude -fPIC -arch x86_64 -O3 -Wall -mmacosx-version-min=10.8 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/Users/csipriuser/Development/ build/third-party/lib/openssl_64/ssl\"" -DENGINESDIR="\"/Users/csipriuser/Development/build/third-party/lib/openssl_64/lib/engines-1.1\"" -DNDEBUG -DPURIFY -DOPENSSL_NO_COMP -MMD -MF crypto/async/arch/async_posix.d.tmp -MT crypto/async/arch/async_posix.o -c -o crypto/async/arch/async_posix.o crypto/async/arch/async_posix.c
cc  -I. -Iinclude -fPIC -arch x86_64 -O3 -Wall -mmacosx-version-min=10.8 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/Users/csipriuser/Development//build/third-party/lib/openssl_64/ssl\"" -DENGINESDIR="\"/Users/csipriuser/Development/build/third-party/lib/openssl_64/lib/engines-1.1\"" -DNDEBUG -DPURIFY -DOPENSSL_NO_COMP -MMD -MF crypto/async/arch/async_win.d.tmp -MT crypto/async/arch/async_win.o -c -o crypto/async/arch/async_win.o crypto/async/arch/async_win.c
cc  -I. -Iinclude -fPIC -arch x86_64 -O3 -Wall -mmacosx-version-min=10.8 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/Users/csipriuser/Development//build/third-party/lib/openssl_64/ssl\"" -DENGINESDIR="\"/Users/csipriuser/Development /build/third-party/lib/openssl_64/lib/engines-1.1\"" -DNDEBUG -DPURIFY -DOPENSSL_NO_COMP -MMD -MF crypto/async/async.d.tmp -MT crypto/async/async.o -c -o crypto/async/async.o crypto/async/async.c
crypto/async/async.c:37:10: warning: implicit declaration of function 'ossl_init_thread_start' is invalid in C99 [-Wimplicit-function-declaration]
    if (!ossl_init_thread_start(OPENSSL_INIT_THREAD_ASYNC))
         ^
crypto/async/async.c:37:33: error: use of undeclared identifier 'OPENSSL_INIT_THREAD_ASYNC'
    if (!ossl_init_thread_start(OPENSSL_INIT_THREAD_ASYNC))
                                ^
crypto/async/async.c:329:33: error: use of undeclared identifier 'OPENSSL_INIT_THREAD_ASYNC'
   if (!ossl_init_thread_start(OPENSSL_INIT_THREAD_ASYNC))
                                ^
1 warning and 2 errors generated.
make[1]: *** [crypto/async/async.o] Error 1
make: *** [all] Error 2


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200613/ee3552d6/attachment-0001.html>

From hmurray at megapathdsl.net  Sat Jun 13 22:47:06 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 13 Jun 2020 15:47:06 -0700
Subject: freefunc - name clash with Python.h
Message-ID: <20200613224706.E734940605C@ip-64-139-1-69.sjc.megapath.net>


I get a blizzard of shadow warnings if Pyhton.h is included along with evp.h.
No problems on 1.1.1g from Fedora.

They go away if I include evp.h first.

/usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of 
???freefunc??? shadows a global declaration [-Wshadow]
  124 |                                          sk_##t1##_freefunc freefunc) \
      |                                          ~~~~~~~~~~~~~~~~~~~^~~~~~~~

I don't know anything about that area.  Is Python's freefunc the same as 
OpenSSL's?  Is this really a warning or a disaster waiting to happen?

Trivial test program attached.
-------------- next part --------------
/* hack to demonstrate freefunc name clash */

/* Build with:
 * cc -Wall -Wshadow -I/usr/include/python3.8 \
 *     -I/usr/local/ssl/include -o freefunc-shadow freefunc-shadow.c
 */

#define PY_SSIZE_T_CLEAN
#include <Python.h>
#include <openssl/evp.h>

int main(int argc, char *argv[])
{
        return 0;
}

-------------- next part --------------
-- 
These are my opinions.  I hate spam.


From rsalz at akamai.com  Sun Jun 14 03:00:39 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 14 Jun 2020 03:00:39 +0000
Subject: freefunc - name clash with Python.h
In-Reply-To: <20200613224706.E734940605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200613224706.E734940605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>

I dlon't lnow about Python's freefunc, no idea what it is, but the OpenSSL line is defining a function with a local parameter named freefunc. Those names shouldn't clash; what compiler and flags?

It should be possible to rename the one in safestack.h to be "freefuncarg" or something.  Can you switch the include order?



From hmurray at megapathdsl.net  Sun Jun 14 04:46:19 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 13 Jun 2020 21:46:19 -0700
Subject: freefunc - name clash with Python.h
In-Reply-To: Message from "Salz, Rich" <rsalz@akamai.com> of "Sun,
 14 Jun 2020 03:00:39 -0000." <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
Message-ID: <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>


Does my test program do anything interesting on your system?

rsalz at akamai.com said:
> I dlon't lnow about Python's freefunc, no idea what it is, but the OpenSSL
> line is defining a function with a local parameter named freefunc. Those
> names shouldn't clash; what compiler and flags?

Python has:
typedef void (*freefunc)(void *);

That looks weird to me, but I'm not a language guy.

$ cc --version
cc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)
(Fedora)

cc -Wshadow -I/usr/include/python3.8 -I/usr/local/ssl/include -o 
freefunc-shadow freefunc-shadow.c


> Can you switch the include order?

That solves my problem.  I was assuming this should get sorted out before release so other users don't get confused.

There are 24 warnings, 535 lines.  Here is everything from the last one.

/usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]
  124 |                                        sk_##t1##_freefunc freefunc) \
      |                                        ~~~~~~~~~~~~~~~~~~~^~~~~~~~

/usr/local/ssl/include/openssl/safestack.h:135:29: note: in expansion of macro ???SKM_DEFINE_STACK_OF???
  135 | # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
      |                             ^~~~~~~~~~~~~~~~~~~
/usr/local/ssl/include/openssl/safestack.h:175:40: note: in expansion of macro ???DEFINE_STACK_OF???
  175 | # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
      |                                        ^~~~~~~~~~~~~~~
/usr/local/ssl/include/openssl/asn1.h:591:1: note: in expansion of macro ???DEFINE_OR_DECLARE_STACK_OF???
  591 | DEFINE_OR_DECLARE_STACK_OF(ASN1_GENERALSTRING)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/python3.8/pytime.h:6,
                 from /usr/include/python3.8/Python.h:85,
                 from freefunc-shadow.c:9:
/usr/include/python3.8/object.h:156:16: note: shadowed declaration is here
  156 | typedef void (*freefunc)(void *);
      |                ^~~~~~~~


Looking closer, there are 12 repeated pairs.

... | grep warning

/usr/local/ssl/include/openssl/safestack.h:90:97: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]
/usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]
/usr/local/ssl/include/openssl/safestack.h:90:97: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]
/usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]
...
/usr/local/ssl/include/openssl/safestack.h:90:97: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]
/usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of ???freefunc??? shadows a global declaration [-Wshadow]


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Sun Jun 14 05:16:27 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 13 Jun 2020 22:16:27 -0700
Subject: PKEY for CMAC: operation not supported for this keytype.
Message-ID: <20200614051627.C82E440605C@ip-64-139-1-69.sjc.megapath.net>

I can't get CMAC to work via PKEY.  I get the same error on 1.1.1g and 3.0.0

I'm using a cipher that works with the CMAC interface.

Can anybody see what I'm missing?

-------------- next part --------------
/* hack to demonstrate pkey troubles */

/* build with:
 * cc -Wall -I/usr/local/ssl/include \
 *     -L/usr/local/ssl/lib -lcrypto -o pkey pkey.c
 */

#include <stdio.h>

#include <openssl/opensslv.h>
#include <openssl/err.h>
#include <openssl/evp.h>

int main(int argc, char *argv[])
{

    const unsigned char key[16];
    const EVP_CIPHER *cipher;
    EVP_PKEY *pkey;
    EVP_PKEY_CTX *ctx;

    printf("Build: %lx, %s\n", \
        OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT);
    printf("Run:   %lx, %s\n", \
        OpenSSL_version_num(), OpenSSL_version(OPENSSL_VERSION));

    cipher = EVP_aes_128_cbc();

    pkey = EVP_PKEY_new_CMAC_key(NULL, key, sizeof(key), cipher);
    if (NULL == pkey) {
        unsigned long err = ERR_get_error();
        char * str = ERR_error_string(err, NULL);
        printf("## Oops, EVP_PKEY_new_CMAC_key() failed:\n    %s.\n", str);
        return 1;
    }

    ctx = EVP_PKEY_CTX_new(pkey, NULL);
    if (NULL == ctx) {
        unsigned long err = ERR_get_error();
        char * str = ERR_error_string(err, NULL);
        printf("## Oops, EVP_PKEY_CTX_new() failed:\n    %s.\n", str);
        return 1;
    }

    if (1 != EVP_PKEY_sign_init(ctx)) {
        unsigned long err = ERR_get_error();
        char * str = ERR_error_string(err, NULL);
        printf("## Oops, EVP_PKEY_sign_init() failed:\n    %s.\n", str);
        return 1;
    }

    /* More here when we get that far. */

    return 0;
}

-------------- next part --------------
-- 
These are my opinions.  I hate spam.


From Matthias.St.Pierre at ncp-e.com  Sun Jun 14 09:54:28 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sun, 14 Jun 2020 09:54:28 +0000
Subject: freefunc - name clash with Python.h
In-Reply-To: <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
References: Message from "Salz, Rich" <rsalz@akamai.com> of "Sun, 14 Jun 2020
 03:00:39 -0000." <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>

> Does my test program do anything interesting on your system?

No. Except for compiling with warnings ;-)

> Python has:
> typedef void (*freefunc)(void *);
> 
> That looks weird to me, but I'm not a language guy.

That's simply a C type definition for a pointer type named `freefunc`, which can hold the address of any function
`foo` which has the signature `void foo(void *)`.  This pointer type is used in various locations by python:

https://github.com/python/cpython/search?p=2&q=freefunc

So Python's global typedef has the same name as a function argument in our headers. The only potential
problem I see here that within one of our functions which has `freefunc` as an argument name, the
global `freefunc` type name would not be available.

You can safely ignore this warning. (Either omit `-Wshadow` entirely, or disable it locally using a #pragma.)

> No problems on 1.1.1g from Fedora.

I was able to trace back the warning to commit 739a1eb1961cdc3b1597a040766f3cb359d095f6 from 2016,
which is included in OpenSSL Versions 1.1.0 and higher. So you should get the warning in 1.1.1g too, unless
Fedora patched the source code.

https://github.com/openssl/openssl/commit/739a1eb1961cdc3b1597a040766f3cb359d095f6


I don't see any reason to change our code, IMHO the clash is Python's fault: it declares a global typedef
with a short name that has no python-specific prefix.


HTH,

Matthias


From levitte at openssl.org  Sun Jun 14 12:22:52 2020
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 14 Jun 2020 14:22:52 +0200
Subject: PKEY for CMAC: operation not supported for this keytype.
In-Reply-To: <20200614051627.C82E440605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200614051627.C82E440605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <87366xq1k3.wl-levitte@openssl.org>

On Sun, 14 Jun 2020 07:16:27 +0200,
Hal Murray wrote:
> 
> I can't get CMAC to work via PKEY.  I get the same error on 1.1.1g and 3.0.0
> 
> I'm using a cipher that works with the CMAC interface.
> 
> Can anybody see what I'm missing?

Yup.  It's designed to work with the set of functions EVP_DigestSign*.

Attached is the diff of your program, rewritten to use that.

Cheers,
Richard

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

===File /tmp/pkey.c.diff====================================
--- /home/levitte/tmp/pkey.c	2020-06-14 14:18:14.351804812 +0200
+++ test-cmac.c	2020-06-14 14:20:04.473406566 +0200
@@ -17,7 +17,7 @@
     const unsigned char key[16];
     const EVP_CIPHER *cipher;
     EVP_PKEY *pkey;
-    EVP_PKEY_CTX *ctx;
+    EVP_MD_CTX *mctx;
 
     printf("Build: %lx, %s\n", \
         OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT);
@@ -34,18 +34,18 @@
         return 1;
     }
 
-    ctx = EVP_PKEY_CTX_new(pkey, NULL);
-    if (NULL == ctx) {
+    mctx = EVP_MD_CTX_new();
+    if (NULL == mctx) {
         unsigned long err = ERR_get_error();
         char * str = ERR_error_string(err, NULL);
         printf("## Oops, EVP_PKEY_CTX_new() failed:\n    %s.\n", str);
         return 1;
     }
 
-    if (1 != EVP_PKEY_sign_init(ctx)) {
+    if (1 != EVP_DigestSignInit(mctx, NULL, NULL, NULL, pkey)) {
         unsigned long err = ERR_get_error();
         char * str = ERR_error_string(err, NULL);
-        printf("## Oops, EVP_PKEY_sign_init() failed:\n    %s.\n", str);
+        printf("## Oops, EVP_PKEY_DigestSignInit() failed:\n    %s.\n", str);
         return 1;
     }
 
============================================================

From hmurray at megapathdsl.net  Sun Jun 14 14:16:17 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 14 Jun 2020 07:16:17 -0700
Subject: PKEY for CMAC: operation not supported for this keytype.
In-Reply-To: Message from Richard Levitte <levitte@openssl.org>
 of "Sun, 14 Jun 2020 14:22:52 +0200." <87366xq1k3.wl-levitte@openssl.org>
Message-ID: <20200614141617.9A20240605C@ip-64-139-1-69.sjc.megapath.net>

Thanks.  It's working now.  Timings soon.

The first paragraph in the man page for EVP_DigestSign and friends says:

The EVP signature routines are a high level interface to digital signatures. 
Input data is digested first before the signing takes place.

Down at the bottom, under CMAC, it says:
    Will ignore any digest provided.

So I assume the first paragraph doesn't apply for CMAC.



-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Sun Jun 14 15:30:50 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 14 Jun 2020 08:30:50 -0700
Subject: CMAC timings
Message-ID: <20200614153050.D8C0E40605C@ip-64-139-1-69.sjc.megapath.net>

In general, things have slowed down.

The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1.
The new PKEY code takes twice as long as the old CMAC code on 1.1.1

The one ray of hope is that the API for EVP_MAC has split the part of the 
setup that uses the key out of the init routine.  If we can hang on to a ctx 
for each key, we can cut the time in half - that's new ECP_MAC vs CMAC on 1.1.1

So how much memory does a ctx take?  How can I find out?

Even if I can't allocate a ctx per key, I can at least keep one around from 
recv to send.   That makes the slowdown 1.7 instead of 3.

----------

Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz

# KL=key length, PL=packet length, CL=CMAC length

# OpenSSL 1.1.1g FIPS  21 Apr 2020

# CMAC        KL PL CL  ns/op sec/run
     AES-128  16 48 16    366   0.366  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    381   0.381  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    407   0.407  991f4017858de97515260dd9ae440b06

# PKEY        KL PL CL  ns/op sec/run
     AES-128  16 48 16    436   0.436  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    448   0.448  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    461   0.461  991f4017858de97515260dd9ae440b06

---------

# OpenSSL 3.0.0-alpha3 4 Jun 2020

# CMAC        KL PL CL  ns/op sec/run
     AES-128  16 48 16    973   0.973  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    987   0.987  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16   1011   1.011  991f4017858de97515260dd9ae440b06

# PKEY        KL PL CL  ns/op sec/run
     AES-128  16 48 16    817   0.817  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    824   0.824  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    842   0.842  991f4017858de97515260dd9ae440b06

# EVP_MAC     KL PL CL  ns/op sec/run
     AES-128  16 48 16   1136   1.136  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16   1153   1.153  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16   1181   1.181  991f4017858de97515260dd9ae440b06

Preload cipher and key.
     AES-128  16 48 16    170   0.170  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    182   0.182  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    196   0.196  991f4017858de97515260dd9ae440b06



-- 
These are my opinions.  I hate spam.




From levitte at openssl.org  Mon Jun 15 05:19:10 2020
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 15 Jun 2020 07:19:10 +0200
Subject: CMAC timings
In-Reply-To: <20200614153050.D8C0E40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200614153050.D8C0E40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <871rmgq52p.wl-levitte@openssl.org>

Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st,
which you find in crypto/evp/evp_local.h.  It's quite small (smaller
than EVP_MD_CTX and EVP_PKEY_CTX):

    struct evp_mac_ctx_st {
        EVP_MAC *meth;               /* Method structure */
        void *data;                  /* Individual method data */
    } /* EVP_MAC_CTX */;

The slowdown isn't entirely surprising...  in pre-3.0, all back-ends
(including engines, with the help of API calls) could reach right into
the EVP_PKEY_CTX that was used by libcrypto code, i.e. central code
and back-end code shared intimate knowledge.  With providers, the
boundary between central code and provider code is much stronger,
which means a certain amount of messaging between the two.

What does surprise me, though, is that direct EVP_MAC calls would be
slower than going through the PKEY bridge.  I would very much like to
see your code to see what's going on.

Regarding preloaded cipher and key, that tells me that the actual
computation of a MAC is quick enough, that most of the slowdown is
parameter overhead.  That was expected.

Cheers,
Richard

On Sun, 14 Jun 2020 17:30:50 +0200,
Hal Murray wrote:
> 
> In general, things have slowed down.
> 
> The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1.
> The new PKEY code takes twice as long as the old CMAC code on 1.1.1
> 
> The one ray of hope is that the API for EVP_MAC has split the part of the 
> setup that uses the key out of the init routine.  If we can hang on to a ctx 
> for each key, we can cut the time in half - that's new ECP_MAC vs CMAC on 1.1.1
> 
> So how much memory does a ctx take?  How can I find out?
> 
> Even if I can't allocate a ctx per key, I can at least keep one around from 
> recv to send.   That makes the slowdown 1.7 instead of 3.
> 
> ----------
> 
> Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
> 
> # KL=key length, PL=packet length, CL=CMAC length
> 
> # OpenSSL 1.1.1g FIPS  21 Apr 2020
> 
> # CMAC        KL PL CL  ns/op sec/run
>      AES-128  16 48 16    366   0.366  475ac1c053379e7dbd4ce80b87d2178e
>      AES-192  24 48 16    381   0.381  c906422bfe0963de6df50e022b4aa7d4
>      AES-256  32 48 16    407   0.407  991f4017858de97515260dd9ae440b06
> 
> # PKEY        KL PL CL  ns/op sec/run
>      AES-128  16 48 16    436   0.436  475ac1c053379e7dbd4ce80b87d2178e
>      AES-192  24 48 16    448   0.448  c906422bfe0963de6df50e022b4aa7d4
>      AES-256  32 48 16    461   0.461  991f4017858de97515260dd9ae440b06
> 
> ---------
> 
> # OpenSSL 3.0.0-alpha3 4 Jun 2020
> 
> # CMAC        KL PL CL  ns/op sec/run
>      AES-128  16 48 16    973   0.973  475ac1c053379e7dbd4ce80b87d2178e
>      AES-192  24 48 16    987   0.987  c906422bfe0963de6df50e022b4aa7d4
>      AES-256  32 48 16   1011   1.011  991f4017858de97515260dd9ae440b06
> 
> # PKEY        KL PL CL  ns/op sec/run
>      AES-128  16 48 16    817   0.817  475ac1c053379e7dbd4ce80b87d2178e
>      AES-192  24 48 16    824   0.824  c906422bfe0963de6df50e022b4aa7d4
>      AES-256  32 48 16    842   0.842  991f4017858de97515260dd9ae440b06
> 
> # EVP_MAC     KL PL CL  ns/op sec/run
>      AES-128  16 48 16   1136   1.136  475ac1c053379e7dbd4ce80b87d2178e
>      AES-192  24 48 16   1153   1.153  c906422bfe0963de6df50e022b4aa7d4
>      AES-256  32 48 16   1181   1.181  991f4017858de97515260dd9ae440b06
> 
> Preload cipher and key.
>      AES-128  16 48 16    170   0.170  475ac1c053379e7dbd4ce80b87d2178e
>      AES-192  24 48 16    182   0.182  c906422bfe0963de6df50e022b4aa7d4
>      AES-256  32 48 16    196   0.196  991f4017858de97515260dd9ae440b06
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl at jordan.maileater.net  Mon Jun 15 06:07:20 2020
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Mon, 15 Jun 2020 06:07:20 +0000
Subject: freefunc - name clash with Python.h
In-Reply-To: <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
References: <rsalz@akamai.com>
 <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
 <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
Message-ID: <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>

On 6/14/2020 2:54 AM, Dr. Matthias St. Pierre wrote:
> I don't see any reason to change our code, IMHO the clash is Python's
> fault: it declares a global typedef with a short name that has no
> python-specific prefix.

That is indeed rude, but the symbol could equally well have been
introduced by the application's header file rather than a library header
file, or the application could be compiled with -Dfreefunc=xxx.

Supplying names for the arguments in function prototypes makes them
easier to read, but risks namespace problems.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200615/514463af/attachment.html>

From openssl-users at dukhovni.org  Mon Jun 15 07:37:18 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 15 Jun 2020 03:37:18 -0400
Subject: freefunc - name clash with Python.h
In-Reply-To: <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>
References: <rsalz@akamai.com>
 <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
 <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
 <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>
Message-ID: <20200615073718.GX48101@straasha.imrryr.org>

On Mon, Jun 15, 2020 at 06:07:20AM +0000, Jordan Brown wrote:

> Supplying names for the arguments in function prototypes makes them
> easier to read, but risks namespace problems.

Yes, which I why, some time back, I argued unsuccessfuly that we SHOULD
NOT use parameter names in public headers in OpenSSL, but sadly was not
able to persuade a majority of the team.

If this is ever reconsidered, my views have not changed.  OpenSSL SHOULD
NOT include parameter names in public headers.

-- 
    Viktor.

From openssl at jordan.maileater.net  Mon Jun 15 19:33:47 2020
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Mon, 15 Jun 2020 19:33:47 +0000
Subject: freefunc - name clash with Python.h
In-Reply-To: <20200615073718.GX48101@straasha.imrryr.org>
References: <rsalz@akamai.com>
 <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
 <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
 <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>
 <20200615073718.GX48101@straasha.imrryr.org>
Message-ID: <01010172b979331e-749124f9-b119-4c5f-9605-8b64dd87c086-000000@us-west-2.amazonses.com>

On 6/15/2020 12:37 AM, Viktor Dukhovni wrote:
> OpenSSL SHOULD NOT include parameter names in public headers. 

It would be sort of, maybe, OK to use names with an appropriate prefix.?
That wouldn't be perfect, but it would be better.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200615/e398e67f/attachment.html>

From hmurray at megapathdsl.net  Wed Jun 17 10:50:05 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 17 Jun 2020 03:50:05 -0700
Subject: CMAC timings
In-Reply-To: Message from Richard Levitte <levitte@openssl.org>
 of "Mon, 15 Jun 2020 07:19:10 +0200." <871rmgq52p.wl-levitte@openssl.org>
Message-ID: <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>

levitte at openssl.org said:
> What does surprise me, though, is that direct EVP_MAC calls would be slower
> than going through the PKEY bridge.  I would very much like to see your code
> to see what's going on. 

Over on an ntpsec list, Kurt Roeckx reported that he was still waiting...

Richard's message said "I", so I sent him a copy off list.  Correcting that...

-------------- next part --------------
/* Last modified on Sat Aug 28 14:30:11 PDT 1999 by murray */

/* Hack to time various implementations of CMAC.
 *
 * This is just the CMAC timing.
 * It doesn't include the copy or compare or finding the right key.
 *
 * Beware of overflows in the timing computations.
 *
 * Disable AES-NI (Intel hardware: NI == New Instruction) with:
 *    OPENSSL_ia32cap="~0x200000200000000"
 * Check /proc/cpuinfo flags for "aes" to see if you have it.
 */

#define CMAC_VERSION_CUTOFF 0x10000003

#include <stdbool.h>
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <time.h>

/* Silence warnings from CMAC routines in OpenSSL 3.0.0 */
#define OPENSSL_SUPPRESS_DEPRECATED 1

#include <openssl/opensslv.h>
#include <openssl/err.h>
#include <openssl/cmac.h>
#include <openssl/ssl.h>
#include <openssl/evp.h>
#include <openssl/rand.h>
#include <openssl/objects.h>
#if OPENSSL_VERSION_NUMBER > 0x20000000L
#include <openssl/params.h> 
#endif

#define UNUSED_ARG(arg)         ((void)(arg))


int NUM = 1000000;

#define PACKET_LENGTH 48
#define MAX_KEY_LENGTH 64

CMAC_CTX *cmac;
#if OPENSSL_VERSION_NUMBER > 0x20000000L
EVP_MAC_CTX *evp;
#endif

unsigned char answer[EVP_MAX_MD_SIZE];

static void ssl_init(void)
{
#if OPENSSL_VERSION_NUMBER > 0x20000000L
	EVP_MAC *mac;
#endif
	ERR_load_crypto_strings();
	OpenSSL_add_all_digests();
	OpenSSL_add_all_ciphers();
	cmac = CMAC_CTX_new();
#if OPENSSL_VERSION_NUMBER > 0x20000000L
	mac = EVP_MAC_fetch(NULL, "cmac", NULL);
	if (NULL == mac)
		printf("## Oops, EVP_MAC_fetch() failed.\n");
	evp = EVP_MAC_CTX_new(mac);
	if (NULL == evp)
		printf("## Oops, EVP_MAC_CTX_new() failed.\n");
#endif
}

static const EVP_CIPHER *CheckCipher(const char *name) {
	const EVP_CIPHER *cipher;
	char cbc[100];
	snprintf(cbc, sizeof(cbc), "%s-CBC", name);
	cipher = EVP_get_cipherbyname(cbc);
	if (0 && NULL == cipher) {
		/* no error available */
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops: EVP_get_cipherbyname() failed: %s\n    %s\n", cbc, str);
		return NULL;
	}
	return cipher;
}

static void PrintHex(const unsigned char* bytes, int length) {
  printf("  ");
  for (int i=0; i<length; i++) {
    printf("%02x", bytes[i]);
  }
}

static size_t One_CMAC(
  const EVP_CIPHER *cipher, /* cipher algorithm */
  uint8_t *key,             /* key pointer */
  int     keylength,        /* key size */
  uint8_t *pkt,             /* packet pointer */
  int     pktlength         /* packet length */
) {
	size_t len;
	if (1 != CMAC_Init(cmac, key, keylength, cipher, NULL)) {
                unsigned long err = ERR_get_error();
                char * str = ERR_error_string(err, NULL);
                printf("## Oops, CMAC_Init() failed:\n    %s.\n", str);
                return 0;
	}
	if (1 != CMAC_Update(cmac, pkt, pktlength)) {
                unsigned long err = ERR_get_error();
                char * str = ERR_error_string(err, NULL);
                printf("## Oops, CMAC_Update() failed:\n    %s.\n", str);
                return 0;
	}
	if (1 != CMAC_Final(cmac, answer, &len)) {
                unsigned long err = ERR_get_error();
                char * str = ERR_error_string(err, NULL);
                printf("## Oops, CMAC_Final() failed:\n    %s.\n", str);
                return 0;
	}
	return len;
}


static void DoCMAC(
  const char *name,       /* name of cipher */
  uint8_t *key,           /* key pointer */
  int     keylength,      /* key length */
  uint8_t *pkt,           /* packet pointer */
  int     pktlength       /* packet length */
)
{
	const EVP_CIPHER *cipher = CheckCipher(name);
	struct timespec start, stop;
	double fast;
	unsigned long digestlength = 0;

	if (NULL == cipher) {
		return;
	}

	clock_gettime(CLOCK_MONOTONIC, &start);
	for (int i = 0; i < NUM; i++) {
		digestlength = One_CMAC(cipher, key, keylength, pkt, pktlength);
		if (0 == digestlength)
			break;
	}
	clock_gettime(CLOCK_MONOTONIC, &stop);
	fast = (stop.tv_sec-start.tv_sec)*1E9 + (stop.tv_nsec-start.tv_nsec);
	printf("%12s  %2d %2d %2lu %6.0f  %6.3f",
	       name, keylength, pktlength, digestlength, fast/NUM,  fast/1E9);
	PrintHex(answer, digestlength);
	printf("\n");
}

#if OPENSSL_VERSION_NUMBER > 0x10101000L
static size_t One_PKEY(
  EVP_PKEY *pkey,
  EVP_MD_CTX *ctx,          /* context  */
  uint8_t *pkt,             /* packet pointer */
  int     pktlength         /* packet length */
) {
	size_t len = EVP_MAX_MD_SIZE;
	if (1 != EVP_DigestSignInit(ctx, NULL, NULL, NULL, pkey)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_DigestSignInit() failed:\n    %s.\n", str);
		return 0;
	}
	EVP_DigestSign(ctx, answer, &len, pkt, pktlength);
	return len;
}


static void DoPKEY(
  const char *name,       /* name of cipher */
  uint8_t *key,           /* key pointer */
  int     keylength,      /* key length */
  uint8_t *pkt,           /* packet pointer */
  int     pktlength       /* packet length */
)
{
	struct timespec start, stop;
	double fast;
	unsigned long digestlength = 0;

	const EVP_CIPHER *cipher = CheckCipher(name);
	EVP_PKEY *pkey;
	EVP_MD_CTX *ctx;

	if (NULL == cipher) {
		return;
	}

	pkey = EVP_PKEY_new_CMAC_key(NULL, key, keylength, cipher);
	if (NULL == pkey) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_PKEY_new_CMAC_key() failed: %s\n    %s.\n", \
			name, str);
		return;
	}
	ctx = EVP_MD_CTX_new();
	if (NULL == ctx) {
		printf("## Oops, EVP_MD_CTX_new() failed.\n");
		return;
	}

	clock_gettime(CLOCK_MONOTONIC, &start);
	for (int i = 0; i < NUM; i++) {
		digestlength = One_PKEY(pkey, ctx, pkt, pktlength);
	}
	clock_gettime(CLOCK_MONOTONIC, &stop);
	fast = (stop.tv_sec-start.tv_sec)*1E9 + (stop.tv_nsec-start.tv_nsec);
	printf("%12s  %2d %2d %2lu %6.0f  %6.3f",
	       name, keylength, pktlength, digestlength, fast/NUM,  fast/1E9);
	PrintHex(answer, digestlength);
	printf("\n");
	EVP_MD_CTX_free(ctx);
	EVP_PKEY_free(pkey);
}
#endif

#if OPENSSL_VERSION_NUMBER > 0x20000000L
static size_t One_EVP_MAC(
  EVP_MAC_CTX *ctx,         /* context  */
  char *cipher,
  uint8_t *key,             /* key pointer */
  int     keylength,        /* key length */
  uint8_t *pkt,             /* packet pointer */
  int     pktlength         /* packet length */
) {
	OSSL_PARAM params[3];
	size_t len = EVP_MAX_MD_SIZE;

	params[0] =
          OSSL_PARAM_construct_utf8_string("cipher", cipher, 0);
	params[1] =
          OSSL_PARAM_construct_octet_string("key", key, keylength);
	params[2] = OSSL_PARAM_construct_end();
	if (0 == EVP_MAC_CTX_set_params(ctx, params)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_CTX_set_params() failed: %s.\n", str);
		return 0;
	}

	if (0 == EVP_MAC_init(ctx)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_init() failed: %s.\n", str);
		return 0;
	}
	if (0 == EVP_MAC_update(ctx, pkt, pktlength)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_init() failed: %s.\n", str);
		return 0;
	}
	if (0 == EVP_MAC_final(ctx, answer, &len, sizeof(answer))) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_init() failed: %s.\n", str);
		return 0;
	}
	return len;
}


static void Do_EVP_MAC(
  const char *name,       /* name of cipher */
  uint8_t *key,           /* key pointer */
  int     keylength,      /* key length */
  uint8_t *pkt,           /* packet pointer */
  int     pktlength       /* packet length */
)
{
	const EVP_CIPHER *cipher = CheckCipher(name);
	struct timespec start, stop;
	double fast;
	unsigned long digestlength = 0;
	char cbc[100];

	if (NULL == cipher) {
		return;
	}
	snprintf(cbc, sizeof(cbc), "%s-CBC", name);


	clock_gettime(CLOCK_MONOTONIC, &start);
	for (int i = 0; i < NUM; i++) {
		digestlength = One_EVP_MAC(evp, cbc, key, keylength, pkt, pktlength);
if (0 == digestlength) break;
	}
	clock_gettime(CLOCK_MONOTONIC, &stop);
	fast = (stop.tv_sec-start.tv_sec)*1E9 + (stop.tv_nsec-start.tv_nsec);
	printf("%12s  %2d %2d %2lu %6.0f  %6.3f",
	       name, keylength, pktlength, digestlength, fast/NUM,  fast/1E9);
	PrintHex(answer, digestlength);
	printf("\n");
}
static size_t One_EVP_MAC2(
  EVP_MAC_CTX *ctx,         /* context  */
  uint8_t *pkt,             /* packet pointer */
  int     pktlength         /* packet length */
) {
	size_t len = EVP_MAX_MD_SIZE;

	if (0 == EVP_MAC_init(ctx)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_init() failed: %s.\n", str);
		return 0;
	}
	if (0 == EVP_MAC_update(ctx, pkt, pktlength)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_init() failed: %s.\n", str);
		return 0;
	}
	if (0 == EVP_MAC_final(ctx, answer, &len, sizeof(answer))) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_init() failed: %s.\n", str);
		return 0;
	}
	return len;
}


static void Do_EVP_MAC2(
  const char *name,       /* name of cipher */
  uint8_t *key,           /* key pointer */
  int     keylength,      /* key length */
  uint8_t *pkt,           /* packet pointer */
  int     pktlength       /* packet length */
)
{
	struct timespec start, stop;
	double fast;
	unsigned long digestlength = 0;
	char cbc[100];
	const EVP_CIPHER *cipher = CheckCipher(name);
	OSSL_PARAM params[3];

	if (NULL == cipher) {
		return;
	}
	snprintf(cbc, sizeof(cbc), "%s-CBC", name);

	params[0] =
          OSSL_PARAM_construct_utf8_string("cipher", cbc, 0);
	params[1] =
          OSSL_PARAM_construct_octet_string("key", key, keylength);
	params[2] = OSSL_PARAM_construct_end();
	if (0 == EVP_MAC_CTX_set_params(evp, params)) {
		unsigned long err = ERR_get_error();
		char * str = ERR_error_string(err, NULL);
		printf("## Oops, EVP_MAC_CTX_set_params() failed: %s.\n", str);
		return;
	}


	clock_gettime(CLOCK_MONOTONIC, &start);
	for (int i = 0; i < NUM; i++) {
		digestlength = One_EVP_MAC2(evp, pkt, pktlength);
if (0 == digestlength) break;
	}
	clock_gettime(CLOCK_MONOTONIC, &stop);
	fast = (stop.tv_sec-start.tv_sec)*1E9 + (stop.tv_nsec-start.tv_nsec);
	printf("%12s  %2d %2d %2lu %6.0f  %6.3f",
	       name, keylength, pktlength, digestlength, fast/NUM,  fast/1E9);
	PrintHex(answer, digestlength);
	printf("\n");
}
#endif

int main(int argc, char *argv[])
{
	uint8_t key[MAX_KEY_LENGTH];
	uint8_t packet[PACKET_LENGTH];

	UNUSED_ARG(argc);
	UNUSED_ARG(argv);

	setlinebuf(stdout);

	ssl_init();
	RAND_bytes((unsigned char *)&key, MAX_KEY_LENGTH);
	RAND_bytes((unsigned char *)&packet, PACKET_LENGTH);
	for (int i=0; i< MAX_KEY_LENGTH; i++) key[i]=i*i+0x23;
	for (int i=0; i< PACKET_LENGTH; i++) packet[i]=i*i+0x31;

	printf("# %s\n", OPENSSL_VERSION_TEXT);

	printf("\n");
	printf("# KL=key length, PL=packet length, CL=CMAC length\n");
	printf("# CMAC        KL PL CL  ns/op sec/run\n");

#if OPENSSL_VERSION_NUMBER < 0x20000000L
/* Hangs on 3.0.0  Checking OPENSSL_NO_DES doesn't work. */
	DoCMAC("DES",          key,  8, packet, PACKET_LENGTH);
#endif
	DoCMAC("DES-EDE",      key, 16, packet, PACKET_LENGTH);
	DoCMAC("DES-EDE3",     key, 24, packet, PACKET_LENGTH);
#ifndef OPENSSL_NO_SM4
	DoCMAC("SM4",          key, 16, packet, PACKET_LENGTH);
#endif
	DoCMAC("AES-128",      key, 16, packet, PACKET_LENGTH);
	DoCMAC("AES-192",      key, 24, packet, PACKET_LENGTH);
	DoCMAC("AES-256",      key, 32, packet, PACKET_LENGTH);
	DoCMAC("CAMELLIA-128", key, 16, packet, PACKET_LENGTH);
	DoCMAC("CAMELLIA-192", key, 24, packet, PACKET_LENGTH);
	DoCMAC("CAMELLIA-256", key, 32, packet, PACKET_LENGTH);
	DoCMAC("ARIA-128",     key, 16, packet, PACKET_LENGTH);
	DoCMAC("ARIA-192",     key, 24, packet, PACKET_LENGTH);
	DoCMAC("ARIA-256",     key, 32, packet, PACKET_LENGTH);

#if OPENSSL_VERSION_NUMBER > 0x10101000L
	printf("\n");
	printf("# KL=key length, PL=packet length, CL=CMAC length\n");
	printf("# PKEY        KL PL CL  ns/op sec/run\n");

#if OPENSSL_VERSION_NUMBER < 0x20000000L
	DoPKEY("DES",          key,  8, packet, PACKET_LENGTH);
#endif
	DoPKEY("DES-EDE",      key, 16, packet, PACKET_LENGTH);
	DoPKEY("DES-EDE3",     key, 24, packet, PACKET_LENGTH);
#ifndef OPENSSL_NO_SM4
	DoPKEY("SM4",          key, 16, packet, PACKET_LENGTH);
#endif
	DoPKEY("AES-128",      key, 16, packet, PACKET_LENGTH);
	DoPKEY("AES-192",      key, 24, packet, PACKET_LENGTH);
	DoPKEY("AES-256",      key, 32, packet, PACKET_LENGTH);
	DoPKEY("CAMELLIA-128", key, 16, packet, PACKET_LENGTH);
	DoPKEY("CAMELLIA-192", key, 24, packet, PACKET_LENGTH);
	DoPKEY("CAMELLIA-256", key, 32, packet, PACKET_LENGTH);
	DoPKEY("ARIA-128",     key, 16, packet, PACKET_LENGTH);
	DoPKEY("ARIA-192",     key, 24, packet, PACKET_LENGTH);
	DoPKEY("ARIA-256",     key, 32, packet, PACKET_LENGTH);
#endif

#if OPENSSL_VERSION_NUMBER > 0x20000000L
	printf("\n");
	printf("# KL=key length, PL=packet length, CL=CMAC length\n");
	printf("# EVP_MAC     KL PL CL  ns/op sec/run\n");

	Do_EVP_MAC("DES-EDE",      key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC("DES-EDE3",     key, 24, packet, PACKET_LENGTH);
#ifndef OPENSSL_NO_SM4
	Do_EVP_MAC("SM4",          key, 16, packet, PACKET_LENGTH);
#endif
	Do_EVP_MAC("AES-128",      key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC("AES-192",      key, 24, packet, PACKET_LENGTH);
	Do_EVP_MAC("AES-256",      key, 32, packet, PACKET_LENGTH);
	Do_EVP_MAC("CAMELLIA-128", key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC("CAMELLIA-192", key, 24, packet, PACKET_LENGTH);
	Do_EVP_MAC("CAMELLIA-256", key, 32, packet, PACKET_LENGTH);
	Do_EVP_MAC("ARIA-128",     key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC("ARIA-192",     key, 24, packet, PACKET_LENGTH);
	Do_EVP_MAC("ARIA-256",     key, 32, packet, PACKET_LENGTH);

	printf("\n");
	printf("Preload cipher and key.\n");
	Do_EVP_MAC2("DES-EDE",      key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC2("DES-EDE3",     key, 24, packet, PACKET_LENGTH);
#ifndef OPENSSL_NO_SM4
	Do_EVP_MAC2("SM4",          key, 16, packet, PACKET_LENGTH);
#endif
	Do_EVP_MAC2("AES-128",      key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC2("AES-192",      key, 24, packet, PACKET_LENGTH);
	Do_EVP_MAC2("AES-256",      key, 32, packet, PACKET_LENGTH);
	Do_EVP_MAC2("CAMELLIA-128", key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC2("CAMELLIA-192", key, 24, packet, PACKET_LENGTH);
	Do_EVP_MAC2("CAMELLIA-256", key, 32, packet, PACKET_LENGTH);
	Do_EVP_MAC2("ARIA-128",     key, 16, packet, PACKET_LENGTH);
	Do_EVP_MAC2("ARIA-192",     key, 24, packet, PACKET_LENGTH);
	Do_EVP_MAC2("ARIA-256",     key, 32, packet, PACKET_LENGTH);
#endif

	return 0;
}
-------------- next part --------------
-- 
These are my opinions.  I hate spam.


From hmurray at megapathdsl.net  Wed Jun 17 11:26:53 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 17 Jun 2020 04:26:53 -0700
Subject: CMAC timings
In-Reply-To: Message from Richard Levitte <levitte@openssl.org>
 of "Mon, 15 Jun 2020 07:19:10 +0200." <871rmgq52p.wl-levitte@openssl.org>
Message-ID: <20200617112653.25AD840605C@ip-64-139-1-69.sjc.megapath.net>

Thanks.

levitte at openssl.org said:
> Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st, which
> you find in crypto/evp/evp_local.h.  It's quite small (smaller than
> EVP_MD_CTX and EVP_PKEY_CTX): 

How much space does the crypto stuff take?  The idea is to do all of the setup 
calculations ahead of time.  I expect there are some tables in there.

> Regarding preloaded cipher and key, that tells me that the actual computation
> of a MAC is quick enough, that most of the slowdown is parameter overhead.
> That was expected. 

There are 2 sorts of overhead.  One is turning the key into a table, or 
something like that.  The other is collecting the parameters and turning them 
into something that can be processed.  Using strings as keys in the params 
tables seems like an invitation for not-fast.  It's probably not significant 
if it is being used from deep inside SSL processing but the total processing 
time for an NTP packet is ballpark of 10 microseconds so difference on that 
scale become interesting.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Wed Jun 17 11:39:35 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 17 Jun 2020 04:39:35 -0700
Subject: Typos in man pages
Message-ID: <20200617113935.AAF7740605C@ip-64-139-1-69.sjc.megapath.net>


There are 3 cases of "structure of NULL" where the "of" should be "or".
The "NULL" is actually "B<NULL>" in the pod file.

doc/man3/EVP_PKEY_CTX_new.pod
doc/man3/X509_NAME_add_entry_by_txt.pod
doc/man3/X509V3_get_d2i.pod

----------

There are several bugs/typos in the example code at the end of  
doc/man3/EVP_MAC.pod

These lines have an extra NULL parameter.
          OSSL_PARAM_construct_utf8_string("cipher", cipher, 0, NULL);
          OSSL_PARAM_construct_utf8_string("digest", digest, 0, NULL);
          OSSL_PARAM_construct_octet_string("key", key, strlen(key), NULL);

----------

That man page describes EVP_MAC_set_ctx_params and uses it in the example:
          || EVP_MAC_set_ctx_params(ctx, params) <= 0)

evp.h has:
int EVP_MAC_CTX_set_params(EVP_MAC_CTX *ctx, const OSSL_PARAM params[]);

That's "set_ctx" vs "CTX_set" in case your eyes doesn't instantly lock on to 
the difference.

There are similar problems with many other ctx routines.
  EVP_MAC_new_ctx => EVP_MAC_CTX_new
  EVP_MAC_free_ctx  => EVP_MAC_CTX_free
  EVP_MAC_get_ctx_params ...






-- 
These are my opinions.  I hate spam.




From kurt at roeckx.be  Wed Jun 17 21:02:54 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 17 Jun 2020 23:02:54 +0200
Subject: CMAC timings
In-Reply-To: <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200617210254.GA380386@roeckx.be>

On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> levitte at openssl.org said:
> > What does surprise me, though, is that direct EVP_MAC calls would be slower
> > than going through the PKEY bridge.  I would very much like to see your code
> > to see what's going on. 
> 
> Over on an ntpsec list, Kurt Roeckx reported that he was still waiting...
> 
> Richard's message said "I", so I sent him a copy off list.  Correcting that...

So I took a look at at the EVP_PKEY case, and it seems we spend most
of our time doing:
- alloc/free. 12 alloc and 16 free calls per signature
- OPENSSL_cleanse: 10 calls per signature
- EVP_CIPHER_CTX_reset: 6 calls per signature

Most of the time is spent in those functions.

The manpage documents:
The call to EVP_DigestSignFinal() internally finalizes a
copy of the digest context. This means that calls to
EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
later to digest and sign additional data.

And:
       EVP_MD_CTX_FLAG_FINALISE
           Some functions such as EVP_DigestSign only finalise
           copies of internal contexts so additional data can be
           included after the finalisation call. This is
           inefficient if this functionality is not required, and
           can be disabled with this flag.

(A reference to the EVP_MD_CTX_set_flags manpage would have been
useful.)

So after the EVP_MD_CTX_new(), I added an:
        EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);

For me it changed things with 3.0 from:
     AES-128  16 48 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
to:
     AES-128  16 48 16    754   0.754  475ac1c053379e7dbd4ce80b87d2178e

While 1.1 gives me this without the change:
     AES-128  16 48 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
and with the change:
     AES-128  16 48 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e

I question the default behaviour, I think most people don't need
that support.


Kurt


From hmurray at megapathdsl.net  Thu Jun 18 01:21:49 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 17 Jun 2020 18:21:49 -0700
Subject: CMAC timings
In-Reply-To: Message from Kurt Roeckx <kurt@roeckx.be>
 of "Wed, 17 Jun 2020 23:02:54 +0200." <20200617210254.GA380386@roeckx.be>
Message-ID: <20200618012149.E1BF440605C@ip-64-139-1-69.sjc.megapath.net>


Thanks.

> The manpage documents: The call to EVP_DigestSignFinal() internally finalizes
> a copy of the digest context. This means that calls to EVP_DigestSignUpdate()
> and EVP_DigestSignFinal() can be called later to digest and sign additional
> data. 

I saw that, but couldn't figure out what it meant.  "additional" suggests that 
it would keep going and sign the current data plus new data.  That didn't seem 
very relevant for my use case.  "another" might be a better word.

Is the idea that it makes the internal state so it is the same as after 
EVP_DigestSignInit()?  If so, that would allow significant CPU savings in the 
request/response case where we sign twice with the same key.


> - alloc/free. 12 alloc and 16 free calls per signature

I'm curious.  12 seems like a huge number.  I'd expect 1.  What's going on?


> And:
>        EVP_MD_CTX_FLAG_FINALISE
>            Some functions such as EVP_DigestSign only finalise
>            copies of internal contexts so additional data can be
>            included after the finalisation call. This is
>            inefficient if this functionality is not required, and
>            can be disabled with this flag. 

Now that you have explained it, I can try to read between the lines.

That "only" seems misleading.

"inefficient if this functionality is not required" doesn't make much sense 
(too me) in the context of finalize.  The inefficiency is that you will have 
to repeat the setup if you want to do another run with the same key.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Thu Jun 18 03:18:42 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 17 Jun 2020 20:18:42 -0700
Subject: PKEY CMAC timings
Message-ID: <20200618031842.6F7B440605C@ip-64-139-1-69.sjc.megapath.net>

Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz

After Kurt's improvement, with our usage patterns (48 bytes), PKEY mode on 
3.0.0 takes 2x as many cycles as 1.1.1

That factor probably depends on how good the hardware AES support is in your 
CPU.  I think it's significantly faster in newer CPU chips.

1.1.1g:
     AES-128  16 48 16    434   0.434  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    442   0.442  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    453   0.453  991f4017858de97515260dd9ae440b06

1.1.1g improved:
     AES-128  16 48 16    230   0.230  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    252   0.252  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    252   0.252  991f4017858de97515260dd9ae440b06

3.0.0 alpha3:
     AES-128  16 48 16    815   0.815  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    831   0.831  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    846   0.846  991f4017858de97515260dd9ae440b06

3.0.0-alpha3 improved:
     AES-128  16 48 16    500   0.500  475ac1c053379e7dbd4ce80b87d2178e
     AES-192  24 48 16    515   0.515  c906422bfe0963de6df50e022b4aa7d4
     AES-256  32 48 16    530   0.530  991f4017858de97515260dd9ae440b06

Thanks again.


-- 
These are my opinions.  I hate spam.




From paul.dale at oracle.com  Thu Jun 18 04:02:49 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 18 Jun 2020 14:02:49 +1000
Subject: PKEY CMAC timings
In-Reply-To: <20200618031842.6F7B440605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200618031842.6F7B440605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <54D080E2-9ACB-461D-B2BD-4FF3F07A1C1F@oracle.com>

How does it look for large input?  As in many kilobytes or megabytes?


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 18 Jun 2020, at 1:18 pm, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
> 
> After Kurt's improvement, with our usage patterns (48 bytes), PKEY mode on 
> 3.0.0 takes 2x as many cycles as 1.1.1
> 
> That factor probably depends on how good the hardware AES support is in your 
> CPU.  I think it's significantly faster in newer CPU chips.
> 
> 1.1.1g:
>     AES-128  16 48 16    434   0.434  475ac1c053379e7dbd4ce80b87d2178e
>     AES-192  24 48 16    442   0.442  c906422bfe0963de6df50e022b4aa7d4
>     AES-256  32 48 16    453   0.453  991f4017858de97515260dd9ae440b06
> 
> 1.1.1g improved:
>     AES-128  16 48 16    230   0.230  475ac1c053379e7dbd4ce80b87d2178e
>     AES-192  24 48 16    252   0.252  c906422bfe0963de6df50e022b4aa7d4
>     AES-256  32 48 16    252   0.252  991f4017858de97515260dd9ae440b06
> 
> 3.0.0 alpha3:
>     AES-128  16 48 16    815   0.815  475ac1c053379e7dbd4ce80b87d2178e
>     AES-192  24 48 16    831   0.831  c906422bfe0963de6df50e022b4aa7d4
>     AES-256  32 48 16    846   0.846  991f4017858de97515260dd9ae440b06
> 
> 3.0.0-alpha3 improved:
>     AES-128  16 48 16    500   0.500  475ac1c053379e7dbd4ce80b87d2178e
>     AES-192  24 48 16    515   0.515  c906422bfe0963de6df50e022b4aa7d4
>     AES-256  32 48 16    530   0.530  991f4017858de97515260dd9ae440b06
> 
> Thanks again.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/15064f32/attachment.html>

From hmurray at megapathdsl.net  Thu Jun 18 04:50:45 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 17 Jun 2020 21:50:45 -0700
Subject: PKEY CMAC timings
In-Reply-To: Message from Dr Paul Dale <paul.dale@oracle.com> of "Thu,
 18 Jun 2020 14:02:49 +1000." <54D080E2-9ACB-461D-B2BD-4FF3F07A1C1F@oracle.com>
Message-ID: <20200618045045.2FAFA40605C@ip-64-139-1-69.sjc.megapath.net>

> How does it look for large input?  As in many kilobytes or megabytes?

16K is all I was willing to wait for.  Timing for really long blocks turns 
into a memory test.  The right unit is ns/byte.  If that's an interesting 
case, I'll hack some code to do longer blocks.

1.1.1g
     AES-128  16 48 16    225   0.225  475ac1c053379e7dbd4ce80b87d2178e
     AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
     AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6

3.0.0 alpha3
     AES-128  16 48 16    496   0.496  475ac1c053379e7dbd4ce80b87d2178e
     AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
     AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6

-----------

3.0.0 alpha3:
CMAC
     AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
PKEY
     AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
EVP_MAC
     AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
EVP_MAC with Preload cipher and key
     AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6



-- 
These are my opinions.  I hate spam.




From levitte at openssl.org  Thu Jun 18 06:27:13 2020
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jun 2020 08:27:13 +0200
Subject: PKEY CMAC timings
In-Reply-To: <20200618045045.2FAFA40605C@ip-64-139-1-69.sjc.megapath.net>
References: <paul.dale@oracle.com>
 <54D080E2-9ACB-461D-B2BD-4FF3F07A1C1F@oracle.com>
 <20200618045045.2FAFA40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <87366sopmm.wl-levitte@openssl.org>

I think 16k was enough to demonstrate that the timing difference
becomes more marginal the larger the amount of data to encrypt in the
same session is.

This makes me think that we might want to rethink the reset functions,
i.e. the likes of EVP_CIPHER_CTX_reset()...  could we change that
function to become a call down to provider code?  We do allow that for
the non-provider back-ends, they can implement a 'cleanup' function.
Right now, EVP_CIPHER_CTX_reset() just calls the provider's function
to free its operation context, which forces us to re-initialize
everything with a restarted session, i.e. pass the key anew, etc etc
etc.

Cheers,
Richard

On Thu, 18 Jun 2020 06:50:45 +0200,
Hal Murray wrote:
> 
> > How does it look for large input?  As in many kilobytes or megabytes?
> 
> 16K is all I was willing to wait for.  Timing for really long blocks turns 
> into a memory test.  The right unit is ns/byte.  If that's an interesting 
> case, I'll hack some code to do longer blocks.
pp> 
> 1.1.1g
>      AES-128  16 48 16    225   0.225  475ac1c053379e7dbd4ce80b87d2178e
>      AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
>      AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6
> 
> 3.0.0 alpha3
>      AES-128  16 48 16    496   0.496  475ac1c053379e7dbd4ce80b87d2178e
>      AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
>      AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6
> 
> -----------
> 
> 3.0.0 alpha3:
> CMAC
>      AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
> PKEY
>      AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
> EVP_MAC
>      AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
> EVP_MAC with Preload cipher and key
>      AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Thu Jun 18 07:04:14 2020
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jun 2020 09:04:14 +0200
Subject: PKEY CMAC timings
In-Reply-To: <87366sopmm.wl-levitte@openssl.org>
References: <paul.dale@oracle.com>
 <54D080E2-9ACB-461D-B2BD-4FF3F07A1C1F@oracle.com>
 <20200618045045.2FAFA40605C@ip-64-139-1-69.sjc.megapath.net>
 <87366sopmm.wl-levitte@openssl.org>
Message-ID: <87zh90n9ch.wl-levitte@openssl.org>

On Thu, 18 Jun 2020 08:27:13 +0200,
Richard Levitte wrote:
> 
> I think 16k was enough to demonstrate that the timing difference
> becomes more marginal the larger the amount of data to encrypt in the
> same session is.
> 
> This makes me think that we might want to rethink the reset functions,
> i.e. the likes of EVP_CIPHER_CTX_reset()...  could we change that
> function to become a call down to provider code?  We do allow that for
> the non-provider back-ends, they can implement a 'cleanup' function.
> Right now, EVP_CIPHER_CTX_reset() just calls the provider's function
> to free its operation context, which forces us to re-initialize
> everything with a restarted session, i.e. pass the key anew, etc etc
> etc.

Never mind what I just said, just calling EVP_EncryptInit_ex(ctx,
NULL, NULL, NULL, NULL) performs (or should perform) the reset I was
thinking of.

Cheers,
Richard

> On Thu, 18 Jun 2020 06:50:45 +0200,
> Hal Murray wrote:
> > 
> > > How does it look for large input?  As in many kilobytes or megabytes?
> > 
> > 16K is all I was willing to wait for.  Timing for really long blocks turns 
> > into a memory test.  The right unit is ns/byte.  If that's an interesting 
> > case, I'll hack some code to do longer blocks.
> pp> 
> > 1.1.1g
> >      AES-128  16 48 16    225   0.225  475ac1c053379e7dbd4ce80b87d2178e
> >      AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
> >      AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6
> > 
> > 3.0.0 alpha3
> >      AES-128  16 48 16    496   0.496  475ac1c053379e7dbd4ce80b87d2178e
> >      AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
> >      AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6
> > 
> > -----------
> > 
> > 3.0.0 alpha3:
> > CMAC
> >      AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
> > PKEY
> >      AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
> > EVP_MAC
> >      AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
> > EVP_MAC with Preload cipher and key
> >      AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6
> > 
> > 
> > 
> > -- 
> > These are my opinions.  I hate spam.
> > 
> > 
> > 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From paul.dale at oracle.com  Thu Jun 18 07:08:58 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 18 Jun 2020 17:08:58 +1000
Subject: PKEY CMAC timings
In-Reply-To: <87366sopmm.wl-levitte@openssl.org>
References: <paul.dale@oracle.com>
 <54D080E2-9ACB-461D-B2BD-4FF3F07A1C1F@oracle.com>
 <20200618045045.2FAFA40605C@ip-64-139-1-69.sjc.megapath.net>
 <87366sopmm.wl-levitte@openssl.org>
Message-ID: <DC31FBBF-79D8-41C1-AFC9-C18831CDCA80@oracle.com>

I honestly believe that the various contexts should be reusable.
Without this, the recent provider additions will impose a significant overhead.

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 18 Jun 2020, at 4:27 pm, Richard Levitte <levitte at openssl.org> wrote:
> 
> I think 16k was enough to demonstrate that the timing difference
> becomes more marginal the larger the amount of data to encrypt in the
> same session is.
> 
> This makes me think that we might want to rethink the reset functions,
> i.e. the likes of EVP_CIPHER_CTX_reset()...  could we change that
> function to become a call down to provider code?  We do allow that for
> the non-provider back-ends, they can implement a 'cleanup' function.
> Right now, EVP_CIPHER_CTX_reset() just calls the provider's function
> to free its operation context, which forces us to re-initialize
> everything with a restarted session, i.e. pass the key anew, etc etc
> etc.
> 
> Cheers,
> Richard
> 
> On Thu, 18 Jun 2020 06:50:45 +0200,
> Hal Murray wrote:
>> 
>>> How does it look for large input?  As in many kilobytes or megabytes?
>> 
>> 16K is all I was willing to wait for.  Timing for really long blocks turns 
>> into a memory test.  The right unit is ns/byte.  If that's an interesting 
>> case, I'll hack some code to do longer blocks.
> pp> 
>> 1.1.1g
>>     AES-128  16 48 16    225   0.225  475ac1c053379e7dbd4ce80b87d2178e
>>     AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
>>     AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6
>> 
>> 3.0.0 alpha3
>>     AES-128  16 48 16    496   0.496  475ac1c053379e7dbd4ce80b87d2178e
>>     AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
>>     AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6
>> 
>> -----------
>> 
>> 3.0.0 alpha3:
>> CMAC
>>     AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
>> PKEY
>>     AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
>> EVP_MAC
>>     AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
>> EVP_MAC with Preload cipher and key
>>     AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6
>> 
>> 
>> 
>> -- 
>> These are my opinions.  I hate spam.
>> 
>> 
>> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/5171372c/attachment.html>

From gareth at garethwilliams.me.uk  Thu Jun 18 07:12:21 2020
From: gareth at garethwilliams.me.uk (Williams, Gareth)
Date: Thu, 18 Jun 2020 08:12:21 +0100
Subject: Multi-valued RDN in Subject Alternative Name extension
Message-ID: <CAOFedGwJvWS+6NPfcdvj=cbgAgawymkjGwgz39fLYhvmi3nSeA@mail.gmail.com>

I can successfully add a multi-value RDN to the Subject of a
certificate request using the + format in the config file:

    distinguished_name = req_dn

    [ req_dn ]
    O=Acme
    CN=Bloggs
    +C=GB

However, if I add a SAN to the request:

    subjectAltName = @alt_names

    [ alt_names ]
    DNS = www.example.com
    dirName = req_dn

the resulting request has them as separate RDNs (as if the + is not noticed).

That is, the resulting subject field is: O = Acme, C = GB + CN = Test
While the resulting SAN extension is: DNS:www.example.com,
DirName:/O=Acme/C=GB/CN=Test

Should multi-value RDNs work in the SAN too?

Kind regards,

Gareth Williams

From hmurray at megapathdsl.net  Thu Jun 18 07:25:43 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 18 Jun 2020 00:25:43 -0700
Subject: PKEY CMAC timings
In-Reply-To: Message from Richard Levitte <levitte@openssl.org>
 of "Thu, 18 Jun 2020 08:27:13 +0200." <87366sopmm.wl-levitte@openssl.org>
Message-ID: <20200618072543.D7E6C40605C@ip-64-139-1-69.sjc.megapath.net>

In the context of making things go fast/clean, do I need a reset?  If so, why?

My straw man is that setup has 3 stages:
  1: get storage and whatever for the cipher
  2: setup tables and such for a key
  3: init internal data

In the same key case, the basic operation is
  Init (does step 3)
  Update
  Final

I think setup steps 1 and 2 can be done with something like
  Setup(ctx, cipher, key+length)

A NULL cipher means keep using the current one - no allocs.

With something like that, I'd be happy to have a ctx per cipher.

Setup and Init can be merged into one function if a NULL key means keep using 
the old one.  I think it's slightly cleaner (and faster) to leave them split.



-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Thu Jun 18 07:39:11 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 18 Jun 2020 00:39:11 -0700
Subject: How can I tell if a name for a cipher/digest is implemented?
Message-ID: <20200618073911.9E5B840605C@ip-64-139-1-69.sjc.megapath.net>


I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
but that changed for 3.0.0

Is there anything better/cleaner than actually calling EVP_CipherInit() or 
such?


I'm curious.  What does it mean to have a non-NULL cipher that doesn't work?  
I'm using default Engines and Providers.  Is that something like we have 
allocated a slot in the name space but this engine doesn't support it?  Should 
there be something like EVP_get_ciphername that takes the engine parameter?

-- 
These are my opinions.  I hate spam.




From ronny.meeus at gmail.com  Thu Jun 18 07:46:52 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 09:46:52 +0200
Subject: endless loop in probable_prime
Message-ID: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>

Hello

we are in the process of upgrading our openssl to version 1.1.1g.
On one of our architectures (Cavium MIPS, running kernel 4.9) we have
an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
core.
On other architectures we do not see the issue at all.

I instrumented the openssl library with some traces and observed that
it keeps on looping in the "probable prime" function.
At the end of the function the "BN_num_bits" check is done and if the
return value is not equal to "bits" it basically starts all over
again.

    }
    if (!BN_add_word(rnd, delta))
        return 0;
    if (BN_num_bits(rnd) != bits) {
        printf("%s BN_num_bits %d %d\n", __FUNCTION__, BN_num_bits(rnd), bits);
        goto again;
    }
    bn_check_top(rnd);
    return 1;
}

I added the print function and the result of the print is as follows:
probable_prime BN_num_bits 1473 1536
This trace keeps on going forever and the values never change.

Any idea what could be the underlying root-cause?

Many thanks and best regards,
Ronny

From matt at openssl.org  Thu Jun 18 08:13:57 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jun 2020 09:13:57 +0100
Subject: Typos in man pages
In-Reply-To: <20200617113935.AAF7740605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200617113935.AAF7740605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <e459b2ad-b40a-0a84-3651-80aa08cdcbed@openssl.org>



On 17/06/2020 12:39, Hal Murray wrote:
> 
> There are 3 cases of "structure of NULL" where the "of" should be "or".
> The "NULL" is actually "B<NULL>" in the pod file.
> 
> doc/man3/EVP_PKEY_CTX_new.pod
> doc/man3/X509_NAME_add_entry_by_txt.pod
> doc/man3/X509V3_get_d2i.pod
> 
> ----------
> 
> There are several bugs/typos in the example code at the end of  
> doc/man3/EVP_MAC.pod
> 
> These lines have an extra NULL parameter.
>           OSSL_PARAM_construct_utf8_string("cipher", cipher, 0, NULL);
>           OSSL_PARAM_construct_utf8_string("digest", digest, 0, NULL);
>           OSSL_PARAM_construct_octet_string("key", key, strlen(key), NULL);
> 
> ----------


I created a PR to fix the above issues:
https://github.com/openssl/openssl/pull/12185



> 
> That man page describes EVP_MAC_set_ctx_params and uses it in the example:
>           || EVP_MAC_set_ctx_params(ctx, params) <= 0)
> 
> evp.h has:
> int EVP_MAC_CTX_set_params(EVP_MAC_CTX *ctx, const OSSL_PARAM params[]);
> 
> That's "set_ctx" vs "CTX_set" in case your eyes doesn't instantly lock on to 
> the difference.
> 
> There are similar problems with many other ctx routines.
>   EVP_MAC_new_ctx => EVP_MAC_CTX_new
>   EVP_MAC_free_ctx  => EVP_MAC_CTX_free
>   EVP_MAC_get_ctx_params ...

These names have recently changed and so there is probably a discrepancy
between whatever version you have locally and what you are reading on
the website. I don't think I agree with the name changes but see:

https://github.com/openssl/openssl/pull/11997

Matt

From tmraz at redhat.com  Thu Jun 18 08:41:40 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 18 Jun 2020 10:41:40 +0200
Subject: CMAC timings
In-Reply-To: <20200617210254.GA380386@roeckx.be>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
Message-ID: <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>

On Wed, 2020-06-17 at 23:02 +0200, Kurt Roeckx wrote:
> On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> > levitte at openssl.org said:
> > > What does surprise me, though, is that direct EVP_MAC calls would
> > > be slower
> > > than going through the PKEY bridge.  I would very much like to
> > > see your code
> > > to see what's going on. 
> > 
> > Over on an ntpsec list, Kurt Roeckx reported that he was still
> > waiting...
> > 
> > Richard's message said "I", so I sent him a copy off
> > list.  Correcting that...
> 
> So I took a look at at the EVP_PKEY case, and it seems we spend most
> of our time doing:
> - alloc/free. 12 alloc and 16 free calls per signature
> - OPENSSL_cleanse: 10 calls per signature
> - EVP_CIPHER_CTX_reset: 6 calls per signature
> 
> Most of the time is spent in those functions.
> 
> The manpage documents:
> The call to EVP_DigestSignFinal() internally finalizes a
> copy of the digest context. This means that calls to
> EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
> later to digest and sign additional data.
> 
> And:
>        EVP_MD_CTX_FLAG_FINALISE
>            Some functions such as EVP_DigestSign only finalise
>            copies of internal contexts so additional data can be
>            included after the finalisation call. This is
>            inefficient if this functionality is not required, and
>            can be disabled with this flag.
> 
> (A reference to the EVP_MD_CTX_set_flags manpage would have been
> useful.)
> 
> So after the EVP_MD_CTX_new(), I added an:
>         EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);
> 
> For me it changed things with 3.0 from:
>      AES-128  16 48
> 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
> to:
>      AES-128  16 48
> 16    754   0.754  475ac1c053379e7dbd4ce80b87d2178e
> 
> While 1.1 gives me this without the change:
>      AES-128  16 48
> 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
> and with the change:
>      AES-128  16 48
> 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e
> 
> I question the default behaviour, I think most people don't need
> that support.

Unfortunately that would be an API break that could be very hard to
discover, so I do not think we can change this even in 3.0.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From guidovranken at gmail.com  Thu Jun 18 09:16:13 2020
From: guidovranken at gmail.com (Guido Vranken)
Date: Thu, 18 Jun 2020 11:16:13 +0200
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
Message-ID: <CAO5O-E+D3XFUfaOMMtZ-CRbvbWOZNscdEvdVFvf=d98oo9HShA@mail.gmail.com>

I think this could be an issue with the system's /dev/urandom or entropy,
as I've observed similar infinite loops in BN_prime when I changed OpenSSL
code to always return the same sequence of bytes from its PRNG (for testing
purposes). It could also be a genuine bug in OpenSSL, or both. I'll let
others comment on that.

On Thu, Jun 18, 2020 at 9:47 AM Ronny Meeus <ronny.meeus at gmail.com> wrote:

> Hello
>
> we are in the process of upgrading our openssl to version 1.1.1g.
> On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
> core.
> On other architectures we do not see the issue at all.
>
> I instrumented the openssl library with some traces and observed that
> it keeps on looping in the "probable prime" function.
> At the end of the function the "BN_num_bits" check is done and if the
> return value is not equal to "bits" it basically starts all over
> again.
>
>     }
>     if (!BN_add_word(rnd, delta))
>         return 0;
>     if (BN_num_bits(rnd) != bits) {
>         printf("%s BN_num_bits %d %d\n", __FUNCTION__, BN_num_bits(rnd),
> bits);
>         goto again;
>     }
>     bn_check_top(rnd);
>     return 1;
> }
>
> I added the print function and the result of the print is as follows:
> probable_prime BN_num_bits 1473 1536
> This trace keeps on going forever and the values never change.
>
> Any idea what could be the underlying root-cause?
>
> Many thanks and best regards,
> Ronny
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/e488326e/attachment.html>

From levitte at openssl.org  Thu Jun 18 09:40:08 2020
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jun 2020 11:40:08 +0200
Subject: How can I tell if a name for a cipher/digest is implemented?
In-Reply-To: <20200618073911.9E5B840605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200618073911.9E5B840605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <87y2okn24n.wl-levitte@openssl.org>

On Thu, 18 Jun 2020 09:39:11 +0200,
Hal Murray wrote:
> I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
> but that changed for 3.0.0
> 
> Is there anything better/cleaner than actually calling EVP_CipherInit() or 
> such?

For 3.0 and on, the better way is to find the cipher with EVP_CIPHER_fetch().
That's essentially the new EVP_get_cipherbyname().

> I'm curious.  What does it mean to have a non-NULL cipher that doesn't work?  

It means that we made a compromise, and do support the use of
functions that return a const EVP_CIPHER, but mainly as a template for
implicit fetching in the likes of EVP_CipherInit.
This is, incidently, what happens if you pass an engine pointer to
EVP_CipherInit_ex() as well, the EVP_CIPHER pointer that you pass to
it is only a template for getting the "real" engine implementation,
and will fail if that engine doesn't implement it.  In other words,
you do have this situation in 1.1.1 as well, just less obviously.

Cheers,
Richard

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

From levitte at openssl.org  Thu Jun 18 09:43:12 2020
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jun 2020 11:43:12 +0200
Subject: PKEY CMAC timings
In-Reply-To: <20200618072543.D7E6C40605C@ip-64-139-1-69.sjc.megapath.net>
References: <levitte@openssl.org> <87366sopmm.wl-levitte@openssl.org>
 <20200618072543.D7E6C40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <87v9jon1zj.wl-levitte@openssl.org>

On Thu, 18 Jun 2020 09:25:43 +0200,
Hal Murray wrote:
> 
> In the context of making things go fast/clean, do I need a reset?  If so, why?

No.  I sent another message where I pointed out that I made a mistake
when saying so.


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

From ronny.meeus at gmail.com  Thu Jun 18 09:58:22 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 11:58:22 +0200
Subject: endless loop in probable_prime
In-Reply-To: <CAO5O-E+D3XFUfaOMMtZ-CRbvbWOZNscdEvdVFvf=d98oo9HShA@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <CAO5O-E+D3XFUfaOMMtZ-CRbvbWOZNscdEvdVFvf=d98oo9HShA@mail.gmail.com>
Message-ID: <CAMJ=MEfnYqTQRH4WAPQPXEE-RvaSiXnRGwZ-TvT3TU1V1P6mpg@mail.gmail.com>

Op do 18 jun. 2020 om 11:16 schreef Guido Vranken <guidovranken at gmail.com>:
>
> I think this could be an issue with the system's /dev/urandom or entropy, as I've observed similar infinite loops in BN_prime when I changed OpenSSL code to always return the same sequence of bytes from its PRNG (for testing purposes). It could also be a genuine bug in OpenSSL, or both. I'll let others comment on that.
>

The HW device that should generate entropy is enabled in the kernel:
~ # zcat /proc/config.gz | grep RANDOM_
CONFIG_HW_RANDOM_TIMERIOMEM=y
CONFIG_HW_RANDOM_OCTEON=y

and the daemon  to populate the data is also running:
~ # ps | grep rngd
 3193 root     /usr/sbin/rngd

Doing the test on the /dev/random also works well:
~ # time dd if=/dev/random of=./out3 bs=1024 count=1 iflag=fullblock
1+0 records in
1+0 records out
real    0m 0.02s
user    0m 0.00s
sys    0m 0.00s

Note that without the daemon operational the dd takes very long so it
looks like the mechanism to generate entropy from the HW is working
well.
When I do an strace on the dd command without the rngd tool running I see:
~ # strace -t dd if=/dev/random of=./out3 bs=1024 count=1 iflag=fullblock
...
12:49:29 openat(AT_FDCWD, "/dev/random", O_RDONLY|O_LARGEFILE) = 3
...
12:49:29 read(0,
"-\335\265BA~Wl\253_\325&$\261\301\6\216\303\326\24q\331\233h\25\205\32(u\343@!"...,
1024) = 72
12:49:29 read(0, "\356\336\32\321\305\304", 952) = 6
12:49:30 read(0, "\233\330\20\240n\312", 946) = 6
12:49:31 read(0, "\25\215A\32\241\246", 940) = 6
12:49:31 read(0, "\350\272\352\350\354V", 934) = 6
12:49:31 read(0, "\274\334u\262\337V", 928) = 6
12:49:31 read(0, "N\243\200\16D>", 922) = 6
12:49:32 read(0, "\34F\333\n%i", 916)   = 6
12:49:32 read(0, "\220\263\344\"\216\374", 910) = 6
12:49:32 read(0, "\27|\305\374V\272", 904) = 6
12:49:32 read(0, "\335\27\374\234\273\356", 898) = 6
12:49:32 read(0, "So\263\242|\207", 892) = 6
12:49:32 read(0, "\207\33\375\236mz", 886) = 6
12:49:34 read(0, "H\375\203v\344J", 880) = 6
12:49:35 read(0, "?o\3\326\334\2", 874) = 6
12:49:36 read(0, ";\22\312\314\237\312", 868) = 6

> On Thu, Jun 18, 2020 at 9:47 AM Ronny Meeus <ronny.meeus at gmail.com> wrote:
>>
>> Hello
>>
>> we are in the process of upgrading our openssl to version 1.1.1g.
>> On one of our architectures (Cavium MIPS, running kernel 4.9) we have
>> an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
>> core.
>> On other architectures we do not see the issue at all.
>>
>> I instrumented the openssl library with some traces and observed that
>> it keeps on looping in the "probable prime" function.
>> At the end of the function the "BN_num_bits" check is done and if the
>> return value is not equal to "bits" it basically starts all over
>> again.
>>
>>     }
>>     if (!BN_add_word(rnd, delta))
>>         return 0;
>>     if (BN_num_bits(rnd) != bits) {
>>         printf("%s BN_num_bits %d %d\n", __FUNCTION__, BN_num_bits(rnd), bits);
>>         goto again;
>>     }
>>     bn_check_top(rnd);
>>     return 1;
>> }
>>
>> I added the print function and the result of the print is as follows:
>> probable_prime BN_num_bits 1473 1536
>> This trace keeps on going forever and the values never change.
>>
>> Any idea what could be the underlying root-cause?
>>
>> Many thanks and best regards,
>> Ronny

From csosz77 at gmail.com  Thu Jun 18 10:00:33 2020
From: csosz77 at gmail.com (Attila Csosz)
Date: Thu, 18 Jun 2020 12:00:33 +0200
Subject: problem with my code
Message-ID: <CAMYm8FpWO-SM_GLh97LtCfRETP_oM18P45hEL4R4cknPW4Po8Q@mail.gmail.com>

Hi,

I'm trying to connect to www.google.com on 443 port with SSL but my code
shows an error at ssl_write.
This code is written in C++ Builder on Windows.
Everything is good before this point
 err = SSL_write(ssl, buf, strlen(buf));

But after that err=-1 and code=1 (means SSL_ERROR_SSL )

What may the problem?

My question also: I have found that maybe I have to use ERR_get_error but
this function is in an another dll (libeay32) how will this function
connect to the ssl instance?

Thanks for your help


void init_openssl()
{
    SSL_load_error_strings();
    SSL_library_init();
}

AnsiString s, HEADERS = "GET /search?q=test HTTP/1.1\r\nHost:
www.google.com\r\nUser-Agent:
OpenSSL\r\n\r\n";

void TestProc()
{
 WORD wVersionRequested;
 WSADATA wsaData;
 struct sockaddr_in sa;
 PSSL_METHOD meth;
 u_long iMode = 1;
 char buf[1024];

 strcpy(buf, HEADERS.c_str());

 wVersionRequested = MAKEWORD(2, 2);
 err = WSAStartup(wVersionRequested, &wsaData);
 if (err != 0) throw Exception("WSAStartup");

 init_openssl();

 // Create socket
 sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP  );
 memset(&sa, 0, sizeof(sa));
 sa.sin_family      = AF_INET;
 sa.sin_addr.s_addr = inet_addr("216.58.213.4");   /* Server IP : this
google.com */
 sa.sin_port        = htons(443);                  /* Server Port number */
 err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));
 if (err == -1) throw Exception("SOCKET: connect");
 err = ioctlsocket(sd, FIONBIO, &iMode);
 if (err == -1) throw Exception("SOCKET: set blocking mode");

 // Create SSL context
 meth = SSLv23_server_method();
 if (!meth) throw Exception("SSL: method");
 ctx = SSL_CTX_new(meth);
 if (!meth) throw Exception("SSL: context");
 ssl = SSL_new(ctx);
 if (!ssl) throw Exception("SSL: ssl");
 SSL_set_fd(ssl, sd);

 // Connect
 err = SSL_connect(ssl);
 if (err == -1) throw Exception("SSL: SSL_connect");

 // Send
 s = HEADERS;
 err = SSL_write(ssl, buf, strlen(buf));   /* error at this point, code =
SSL_ERROR_SSL */
 code = SSL_get_error(ssl, err);
 if (err == -1) throw Exception("SSL: send: "+s);
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/c1508eab/attachment.html>

From matt at openssl.org  Thu Jun 18 13:32:45 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jun 2020 14:32:45 +0100
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
Message-ID: <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>



On 18/06/2020 08:46, Ronny Meeus wrote:
> Hello
> 
> we are in the process of upgrading our openssl to version 1.1.1g.
> On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
> core.
> On other architectures we do not see the issue at all.
> 
> I instrumented the openssl library with some traces and observed that
> it keeps on looping in the "probable prime" function.
> At the end of the function the "BN_num_bits" check is done and if the
> return value is not equal to "bits" it basically starts all over
> again.
> 
>     }
>     if (!BN_add_word(rnd, delta))
>         return 0;
>     if (BN_num_bits(rnd) != bits) {
>         printf("%s BN_num_bits %d %d\n", __FUNCTION__, BN_num_bits(rnd), bits);
>         goto again;
>     }
>     bn_check_top(rnd);
>     return 1;
> }
> 
> I added the print function and the result of the print is as follows:
> probable_prime BN_num_bits 1473 1536

Hmm. That is very suspicious. I wonder if the generated number in `rnd`
is actually different each time? Can you check?

Matt



> This trace keeps on going forever and the values never change.
> 
> Any idea what could be the underlying root-cause?
> 
> Many thanks and best regards,
> Ronny
> 

From uri at ll.mit.edu  Thu Jun 18 14:12:56 2020
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 18 Jun 2020 14:12:56 +0000
Subject: CMAC timings
In-Reply-To: <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
 <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
Message-ID: <9F4FFBC1-4CA2-4E19-A955-5E46DB008EEB@ll.mit.edu>

I think that the default behavior should change for 3.0, and the API change described in the Release Notes. I find that alternative less impacting that this silent sudden performance deterioration.


?On 6/18/20, 04:42, "openssl-users on behalf of Tomas Mraz" <openssl-users-bounces at openssl.org on behalf of tmraz at redhat.com> wrote:

    On Wed, 2020-06-17 at 23:02 +0200, Kurt Roeckx wrote:
    > On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
    > > levitte at openssl.org said:
    > > > What does surprise me, though, is that direct EVP_MAC calls would
    > > > be slower
    > > > than going through the PKEY bridge.  I would very much like to
    > > > see your code
    > > > to see what's going on. 
    > > 
    > > Over on an ntpsec list, Kurt Roeckx reported that he was still
    > > waiting...
    > > 
    > > Richard's message said "I", so I sent him a copy off
    > > list.  Correcting that...
    > 
    > So I took a look at at the EVP_PKEY case, and it seems we spend most
    > of our time doing:
    > - alloc/free. 12 alloc and 16 free calls per signature
    > - OPENSSL_cleanse: 10 calls per signature
    > - EVP_CIPHER_CTX_reset: 6 calls per signature
    > 
    > Most of the time is spent in those functions.
    > 
    > The manpage documents:
    > The call to EVP_DigestSignFinal() internally finalizes a
    > copy of the digest context. This means that calls to
    > EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
    > later to digest and sign additional data.
    > 
    > And:
    >        EVP_MD_CTX_FLAG_FINALISE
    >            Some functions such as EVP_DigestSign only finalise
    >            copies of internal contexts so additional data can be
    >            included after the finalisation call. This is
    >            inefficient if this functionality is not required, and
    >            can be disabled with this flag.
    > 
    > (A reference to the EVP_MD_CTX_set_flags manpage would have been
    > useful.)
    > 
    > So after the EVP_MD_CTX_new(), I added an:
    >         EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);
    > 
    > For me it changed things with 3.0 from:
    >      AES-128  16 48
    > 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
    > to:
    >      AES-128  16 48
    > 16    754   0.754  475ac1c053379e7dbd4ce80b87d2178e
    > 
    > While 1.1 gives me this without the change:
    >      AES-128  16 48
    > 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
    > and with the change:
    >      AES-128  16 48
    > 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e
    > 
    > I question the default behaviour, I think most people don't need
    > that support.

    Unfortunately that would be an API break that could be very hard to
    discover, so I do not think we can change this even in 3.0.

    -- 
    Tom?? Mr?z
    No matter how far down the wrong road you've gone, turn back.
                                                  Turkish proverb
    [You'll know whether the road is wrong if you carefully listen to your
    conscience.]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/6ff92ba8/attachment-0001.bin>

From openssl-users at dukhovni.org  Thu Jun 18 14:12:26 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 Jun 2020 10:12:26 -0400
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
Message-ID: <20200618141226.GO36399@straasha.imrryr.org>

On Thu, Jun 18, 2020 at 09:46:52AM +0200, Ronny Meeus wrote:

> we are in the process of upgrading our openssl to version 1.1.1g.
> On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
> core.

Have you tried building OpenSSL with no assembly optimizations?

-- 
    Viktor.

From openssl-users at dukhovni.org  Thu Jun 18 14:20:31 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 Jun 2020 10:20:31 -0400
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
Message-ID: <20200618142031.GP36399@straasha.imrryr.org>

On Thu, Jun 18, 2020 at 09:46:52AM +0200, Ronny Meeus wrote:

> I added the print function and the result of the print is as follows:
> probable_prime BN_num_bits 1473 1536

The difference is exactly 63 bits!  Suggesting that either the high
64-bit bit word is 0x0000000000000001 or the bit counting is not
working right.

What is the "endianness" of this CPU?  Is it big-endian or
little-endian?  And does OpenSSL expect the correct one?

-- 
    Viktor.

From ronny.meeus at gmail.com  Thu Jun 18 15:06:50 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 17:06:50 +0200
Subject: endless loop in probable_prime
In-Reply-To: <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
Message-ID: <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>

Op do 18 jun. 2020 om 15:33 schreef Matt Caswell <matt at openssl.org>:
>
>
>
> On 18/06/2020 08:46, Ronny Meeus wrote:
> > Hello
> >
> > we are in the process of upgrading our openssl to version 1.1.1g.
> > On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> > an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
> > core.
> > On other architectures we do not see the issue at all.
> >
> > I instrumented the openssl library with some traces and observed that
> > it keeps on looping in the "probable prime" function.
> > At the end of the function the "BN_num_bits" check is done and if the
> > return value is not equal to "bits" it basically starts all over
> > again.
> >
> >     }
> >     if (!BN_add_word(rnd, delta))
> >         return 0;
> >     if (BN_num_bits(rnd) != bits) {
> >         printf("%s BN_num_bits %d %d\n", __FUNCTION__, BN_num_bits(rnd), bits);
> >         goto again;
> >     }
> >     bn_check_top(rnd);
> >     return 1;
> > }
> >
> > I added the print function and the result of the print is as follows:
> > probable_prime BN_num_bits 1473 1536
>
> Hmm. That is very suspicious. I wonder if the generated number in `rnd`
> is actually different each time? Can you check?
>

I instrumented both the "probable_prime" and the "bnrand" functions as
you can see below and the values actually change (see below).
But what is strange is that the value of "rnd->size" is only 24 and
the size of the sizeof(rnd->d) is 4 bytes = 32 bits which results only
in 768 bits (24*32) while the number of bits requested is 1536.
So there is a problem with the calculation of the size.
It might have to do with the fact that we run on a 64b kernel with a
32b user land and that we use only 1 toolchain to compile both the
kernel and the user-land.

probable_prime BN_num_bits=1473 bits=1536
BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
dd5068b3f6658f33b701d31f0b72aa1e6ccd5e4aed5039b32e8d301eefa0c5a4befaa4877a6ff9c131ef974bd3538496acaed1bd442ad0af60a30f5f8bd364d0a0eb31643135aecfec65bcb1074a4f4667f03cee235765ed5cc59801768380db

probable_prime 0 loop=228 again=114
bnrand bits=1536 top=1 bottom=1 bytes=192
data: ff ec 15 94 95 10 ca 68 0f 54 06 0f b9 14 bc da 5d 33 58 4e 3e
35 ca d5 30 c8 33 a5 c1 61 7f d6 00 26 98 45 df 73 34 3c 32 74 89 e2
da 03 72 20 fe 50 23 85 e7 a0 a6 97 27 38 e8 3e 4d 1d d6 11 66 93 d2
01 40 5a 9e 23 31 1f a8 a8 7c 46 c9 eb 79 02 44 9d 9c a7 fe 5e 80 f4
0b 68 ec a5 2f 59 59 a3 02 56 6b 16 7a 01 a5 bb 3c c9 28 71 3b f5 44
30 a3 00 fb f0 de 65 2a 28 8d 8b 8d 2c 71 84 65 33 a9 73 8d 4e ce d4
86 ce 1e 6d d7 2f a4 2d 6c 1c 27 88 0e 2a 0c 09 d0 ff 10 e7 55 7b 55
a9 34 5c 36 88 c9 03 64 f2 ac ae cc 64 f7 a2 3c 6d 62 72 55 8d 99 69
20 2e 33 8b b6 21 20 dd 57 ef


probable_prime BN_num_bits=1473 bits=1536
BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
20dd57f19969202ef7a23c6dc90364f2557b55a90e2a0c09d72fa42d8d4eced48d2c7184fbf0de6528713bf56b167a01eca52f599ca7fe5e7c46c9eb405a9e234d1dd611e7a0a697da037220df73343cc1617fd63e35cad5b914bcda9510ca68

probable_prime 0 loop=230 again=115
bnrand bits=1536 top=1 bottom=1 bytes=192
data: fb 14 f4 1d 93 a7 4e 05 7e 25 2c 7e cd d7 28 c1 04 ad 7d 98 11
7c 11 6e 37 6a fd ed c9 e4 a0 e0 2c 08 76 49 35 1f 5e 12 9c d9 58 be
f6 da 74 71 16 5e 5d 79 f8 8f 2e 3b 8a 97 d4 bb 0b ee fc 2e 9f 30 27
9a da 66 1e b5 5f ba 55 40 7b dd c3 2e 5d b2 2c ed 69 07 06 d6 83 80
82 75 7f 88 3e bf bf ee 4f 91 ca 87 1f 19 4e 62 ac 27 cd e4 60 14 78
98 c4 29 78 14 70 3a 7f 04 25 77 11 f7 7f 1a 18 1b 8b e6 36 47 aa a9
ac 7a 0b c1 2b a7 f6 2c 7d ce 2c e4 6e e4 76 6d 5f cc 13 81 48 55 83
b2 53 15 86 8a b2 3e ce fc 30 66 10 78 70 00 15 0e 91 8e 06 f7 b3 05
57 ca 92 3c fa d8 8b b7 a9 6b


probable_prime BN_num_bits=1473 bits=1536
BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
8bb7a96db30557ca7000150eb23ecefc485583b26ee4766d2ba7f62c3647aaa911f77f1a7814703acde46014ca871f197f883ebf690706d67bddc32eda661eb50beefc2ef88f2e3bf6da7471351f5e12c9e4a0e0117c116ecdd728c193a74e05

probable_prime 0 loop=232 again=116
bnrand bits=1536 top=1 bottom=1 bytes=192
data: ec 3f f5 df 8f 59 fe 52 2c db 38 22 1e bf 09 45 76 d4 74 d5 d7
c7 94 fe 4f 61 af d9 56 f3 b6 79 3b a9 91 ce ef 47 91 db b7 8c 66 1d
db f3 d9 91 51 1c 81 42 ff 8d 7a 6c 81 0f 48 52 d8 50 39 b1 68 29 79
a0 83 ac b0 f1 2b 4a 92 10 0f f2 1f 7a dd b7 6f f2 10 fa d7 2d ca cc
98 94 a5 c5 74 a1 67 de 44 85 f3 5a 64 14 d6 bc 3d 7d 1b 5a 69 1b f4
ff b8 28 2f dc c3 b6 e2 d9 e4 bd c4 bc b4 d1 a7 b5 0b 04 8a 87 50 0f
f3 36 06 e8 55 1d 8a ef 66 b5 2d d2 c1 86 87 cb 5b 58 30 12 a9 80 04
bf c2 80 44 af 01 91 1b 97 ca 8c 32 0b f7 47 30 e8 b4 8e d9 fb c5 7b
87 e5 66 61 be 80 56 f5 bd f3



>
>
> > This trace keeps on going forever and the values never change.
> >
> > Any idea what could be the underlying root-cause?
> >
> > Many thanks and best regards,
> > Ronny
> >

From ronny.meeus at gmail.com  Thu Jun 18 15:10:08 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 17:10:08 +0200
Subject: endless loop in probable_prime
In-Reply-To: <20200618142031.GP36399@straasha.imrryr.org>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <20200618142031.GP36399@straasha.imrryr.org>
Message-ID: <CAMJ=MEd5E9GK+z5YnD8Ze6ZpQ_tq-CN9EvyhGMy5gCGPS8vbDQ@mail.gmail.com>

Op do 18 jun. 2020 om 16:20 schreef Viktor Dukhovni
<openssl-users at dukhovni.org>:
>
> On Thu, Jun 18, 2020 at 09:46:52AM +0200, Ronny Meeus wrote:
>
> > I added the print function and the result of the print is as follows:
> > probable_prime BN_num_bits 1473 1536
>
> The difference is exactly 63 bits!  Suggesting that either the high
> 64-bit bit word is 0x0000000000000001 or the bit counting is not
> working right.
>
> What is the "endianness" of this CPU?  Is it big-endian or
> little-endian?  And does OpenSSL expect the correct one?
>

This is a big endian CPU.

From matt at openssl.org  Thu Jun 18 15:43:32 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jun 2020 16:43:32 +0100
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
Message-ID: <27485cd4-c665-607b-25bf-15926224f386@openssl.org>



On 18/06/2020 16:06, Ronny Meeus wrote:
> probable_prime BN_num_bits=1473 bits=1536
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
> dd5068b3f6658f33b701d31f0b72aa1e6ccd5e4aed5039b32e8d301eefa0c5a4befaa4877a6ff9c131ef974bd3538496acaed1bd442ad0af60a30f5f8bd364d0a0eb31643135aecfec65bcb1074a4f4667f03cee235765ed5cc59801768380db
> 
> probable_prime 0 loop=228 again=114
> bnrand bits=1536 top=1 bottom=1 bytes=192
> data: ff ec 15 94 95 10 ca 68 0f 54 06 0f b9 14 bc da 5d 33 58 4e 3e
> 35 ca d5 30 c8 33 a5 c1 61 7f d6 00 26 98 45 df 73 34 3c 32 74 89 e2
> da 03 72 20 fe 50 23 85 e7 a0 a6 97 27 38 e8 3e 4d 1d d6 11 66 93 d2
> 01 40 5a 9e 23 31 1f a8 a8 7c 46 c9 eb 79 02 44 9d 9c a7 fe 5e 80 f4
> 0b 68 ec a5 2f 59 59 a3 02 56 6b 16 7a 01 a5 bb 3c c9 28 71 3b f5 44
> 30 a3 00 fb f0 de 65 2a 28 8d 8b 8d 2c 71 84 65 33 a9 73 8d 4e ce d4
> 86 ce 1e 6d d7 2f a4 2d 6c 1c 27 88 0e 2a 0c 09 d0 ff 10 e7 55 7b 55
> a9 34 5c 36 88 c9 03 64 f2 ac ae cc 64 f7 a2 3c 6d 62 72 55 8d 99 69
> 20 2e 33 8b b6 21 20 dd 57 ef

So, it looks to me like in bnrand things are as we expect them to be. We
do generate 192 bytes (1536) bits of data. My guess is things go wrong
right near the end of bnrand when we convert the data into a BIGNUM via
the BN_bin2bn call.

It looks to me like there is a discrepancy between what OpenSSL thinks
the size of a word is and what the actual size of a word is:

> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):

24 * 4 * 8 = 768 bits (exactly half of 1536) in spite of the 1473 that
BN_num_bits is reporting.

BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
should also be 4. If BN_BYTES is being incorrectly set to 8 on your
platform then that would explain the discrepancy. Can you check?


Matt




> 
> 
> probable_prime BN_num_bits=1473 bits=1536
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
> 20dd57f19969202ef7a23c6dc90364f2557b55a90e2a0c09d72fa42d8d4eced48d2c7184fbf0de6528713bf56b167a01eca52f599ca7fe5e7c46c9eb405a9e234d1dd611e7a0a697da037220df73343cc1617fd63e35cad5b914bcda9510ca68
> 
> probable_prime 0 loop=230 again=115
> bnrand bits=1536 top=1 bottom=1 bytes=192
> data: fb 14 f4 1d 93 a7 4e 05 7e 25 2c 7e cd d7 28 c1 04 ad 7d 98 11
> 7c 11 6e 37 6a fd ed c9 e4 a0 e0 2c 08 76 49 35 1f 5e 12 9c d9 58 be
> f6 da 74 71 16 5e 5d 79 f8 8f 2e 3b 8a 97 d4 bb 0b ee fc 2e 9f 30 27
> 9a da 66 1e b5 5f ba 55 40 7b dd c3 2e 5d b2 2c ed 69 07 06 d6 83 80
> 82 75 7f 88 3e bf bf ee 4f 91 ca 87 1f 19 4e 62 ac 27 cd e4 60 14 78
> 98 c4 29 78 14 70 3a 7f 04 25 77 11 f7 7f 1a 18 1b 8b e6 36 47 aa a9
> ac 7a 0b c1 2b a7 f6 2c 7d ce 2c e4 6e e4 76 6d 5f cc 13 81 48 55 83
> b2 53 15 86 8a b2 3e ce fc 30 66 10 78 70 00 15 0e 91 8e 06 f7 b3 05
> 57 ca 92 3c fa d8 8b b7 a9 6b
> 
> 
> probable_prime BN_num_bits=1473 bits=1536
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
> 8bb7a96db30557ca7000150eb23ecefc485583b26ee4766d2ba7f62c3647aaa911f77f1a7814703acde46014ca871f197f883ebf690706d67bddc32eda661eb50beefc2ef88f2e3bf6da7471351f5e12c9e4a0e0117c116ecdd728c193a74e05
> 
> probable_prime 0 loop=232 again=116
> bnrand bits=1536 top=1 bottom=1 bytes=192
> data: ec 3f f5 df 8f 59 fe 52 2c db 38 22 1e bf 09 45 76 d4 74 d5 d7
> c7 94 fe 4f 61 af d9 56 f3 b6 79 3b a9 91 ce ef 47 91 db b7 8c 66 1d
> db f3 d9 91 51 1c 81 42 ff 8d 7a 6c 81 0f 48 52 d8 50 39 b1 68 29 79
> a0 83 ac b0 f1 2b 4a 92 10 0f f2 1f 7a dd b7 6f f2 10 fa d7 2d ca cc
> 98 94 a5 c5 74 a1 67 de 44 85 f3 5a 64 14 d6 bc 3d 7d 1b 5a 69 1b f4
> ff b8 28 2f dc c3 b6 e2 d9 e4 bd c4 bc b4 d1 a7 b5 0b 04 8a 87 50 0f
> f3 36 06 e8 55 1d 8a ef 66 b5 2d d2 c1 86 87 cb 5b 58 30 12 a9 80 04
> bf c2 80 44 af 01 91 1b 97 ca 8c 32 0b f7 47 30 e8 b4 8e d9 fb c5 7b
> 87 e5 66 61 be 80 56 f5 bd f3
> 
> 
> 
>>
>>
>>> This trace keeps on going forever and the values never change.
>>>
>>> Any idea what could be the underlying root-cause?
>>>
>>> Many thanks and best regards,
>>> Ronny
>>>
> 

From openssl-users at dukhovni.org  Thu Jun 18 16:02:04 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 Jun 2020 12:02:04 -0400
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <CAMJ=MEd5E9GK+z5YnD8Ze6ZpQ_tq-CN9EvyhGMy5gCGPS8vbDQ@mail.gmail.com>
Message-ID: <20200618160204.GR36399@straasha.imrryr.org>

On Thu, Jun 18, 2020 at 05:10:08PM +0200, Ronny Meeus wrote:

> > What is the "endianness" of this CPU?  Is it big-endian or
> > little-endian?  And does OpenSSL expect the correct one?
> 
> This is a big endian CPU.

And, is OpenSSL configured for the correct endianness?

On Thu, Jun 18, 2020 at 05:06:50PM +0200, Ronny Meeus wrote:

> I instrumented both the "probable_prime" and the "bnrand" functions as
> you can see below and the values actually change (see below).
> But what is strange is that the value of "rnd->size" is only 24 and
> the size of the sizeof(rnd->d) is 4 bytes = 32 bits which results only

If rnd->d is a pointer, you want sizeof(rnd->d[0]).  Or if you
literrally mean "sizeof(sizeof(rnd->d))" than that's expected with a
32-bit address space.  Either way, you're perhaps reporting a misleading
value.

> So there is a problem with the calculation of the size.

Or not.

> It might have to do with the fact that we run on a 64b kernel with a
> 32b user land and that we use only 1 toolchain to compile both the
> kernel and the user-land.

The size of the address space (size of pointers) should not matter,
what matters are the sizes "int", "long", "long long", ...

> probable_prime 0 loop=228 again=114
> bnrand bits=1536 top=1 bottom=1 bytes=192
> data: ff ec 15 94 95 10 ca 68 0f 54 06 0f b9 14 bc da 5d 33 58 4e 3e
                    ----  5 ---
> 35 ca d5 30 c8 33 a5 c1 61 7f d6 00 26 98 45 df 73 34 3c 32 74 89 e2
> da 03 72 20 fe 50 23 85 e7 a0 a6 97 27 38 e8 3e 4d 1d d6 11 66 93 d2
> 01 40 5a 9e 23 31 1f a8 a8 7c 46 c9 eb 79 02 44 9d 9c a7 fe 5e 80 f4
> 0b 68 ec a5 2f 59 59 a3 02 56 6b 16 7a 01 a5 bb 3c c9 28 71 3b f5 44
> 30 a3 00 fb f0 de 65 2a 28 8d 8b 8d 2c 71 84 65 33 a9 73 8d 4e ce d4
> 86 ce 1e 6d d7 2f a4 2d 6c 1c 27 88 0e 2a 0c 09 d0 ff 10 e7 55 7b 55
> a9 34 5c 36 88 c9 03 64 f2 ac ae cc 64 f7 a2 3c 6d 62 72 55 8d 99 69
                 ----  4 ---             ----  3 ---             ---- 
> 20 2e 33 8b b6 21 20 dd 57 ef
  2 ---             ---- 1  ---

> probable_prime BN_num_bits=1473 bits=1536
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
> 20dd57f1 9969202e f7a23c6d c90364f2 [...] 9510ca68
  --  1 -- --  2 -- --  3 -- --  4 -- ...   --  5 --

However, clearly the hex output above captures only every other 32-bits
of the actual byte array.  Perhaps there's something wrong with your
compilation tool-chain.

-- 
    Viktor.

From rsalz at akamai.com  Thu Jun 18 16:13:47 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jun 2020 16:13:47 +0000
Subject: endless loop in probable_prime
In-Reply-To: <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
Message-ID: <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>

>    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
    BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
    should also be 4. If BN_BYTES is being incorrectly set to 8 on your
    platform then that would explain the discrepancy. Can you check?

This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?


From ronny.meeus at gmail.com  Thu Jun 18 16:27:05 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 18:27:05 +0200
Subject: endless loop in probable_prime
In-Reply-To: <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
Message-ID: <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>

Op do 18 jun. 2020 om 18:13 schreef Salz, Rich <rsalz at akamai.com>:
>
> >    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
>     BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
>     should also be 4. If BN_BYTES is being incorrectly set to 8 on your
>     platform then that would explain the discrepancy. Can you check?
>
> This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
>

I used the following print statement so the sizeof is actual of the *d
and not of the pointer :-).
printf("BN_num data (size=%d top=%d neg=%d flags=%d, sizeof(*d)=%d)
BN_BYTES=%d: ", rnd->dmax, rnd->top, rnd->neg, rnd->flags,
sizeof(*rnd->d), BN_BYTES);

The output clearly shows that BN_BYTES is 8:

BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=8:
efe838eb2cf627a7cf1944d5969e17602474f949d4e04f33263e49cdc9917b5f4f71f4f27eb06b2f41930dbac791ded7fae69fa604ec65686b412ef048e91cfd8c976e74ff237112406371b6cb2770588328f8db400718366665b6bca733a19c

I think we are getting close to the root-cause here ...

Ronny

From kurt at roeckx.be  Thu Jun 18 16:45:44 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 18 Jun 2020 18:45:44 +0200
Subject: CMAC timings
In-Reply-To: <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
 <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
Message-ID: <20200618164544.GL10682@roeckx.be>

On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
> > I question the default behaviour, I think most people don't need
> > that support.
> 
> Unfortunately that would be an API break that could be very hard to
> discover, so I do not think we can change this even in 3.0.

But I think the old CMAC API didn't support that, and so we can
change the internal calls to use the flag now (if needed). The
EVP_MAC API probably supports this too, and we can consider
changing the default there.


Kurt


From uri at ll.mit.edu  Thu Jun 18 17:11:39 2020
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 18 Jun 2020 17:11:39 +0000
Subject: CMAC timings
In-Reply-To: <20200618164544.GL10682@roeckx.be>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
 <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
 <20200618164544.GL10682@roeckx.be>
Message-ID: <53E9961C-2685-403B-9138-0A8CF887FBA5@ll.mit.edu>

On 6/18/20, 12:46, "openssl-users on behalf of Kurt Roeckx" <openssl-users-bounces at openssl.org on behalf of kurt at roeckx.be> wrote:

    On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
    >> > I question the default behaviour, I think most people don't need
    >> > that support.
    >> 
    >> Unfortunately that would be an API break that could be very hard to
    >> discover, so I do not think we can change this even in 3.0.
    >
    > But I think the old CMAC API didn't support that, and so we can
    > change the internal calls to use the flag now (if needed). The
    > EVP_MAC API probably supports this too, and we can consider
    > changing the default there.

Yes please!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/854c438a/attachment.bin>

From kurt at roeckx.be  Thu Jun 18 17:24:39 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 18 Jun 2020 19:24:39 +0200
Subject: CMAC timings
In-Reply-To: <9F4FFBC1-4CA2-4E19-A955-5E46DB008EEB@ll.mit.edu>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
 <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
 <9F4FFBC1-4CA2-4E19-A955-5E46DB008EEB@ll.mit.edu>
Message-ID: <20200618172439.GA433646@roeckx.be>

On Thu, Jun 18, 2020 at 02:12:56PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> I think that the default behavior should change for 3.0, and the API change described in the Release Notes. I find that alternative less impacting that this silent sudden performance deterioration.

Note that I was just looking at why the EVP PKEY API was slow, and
the first thing I found was the EVP_MD_CTX_FLAG_FINALISE's impact.
This also has a big impact in the 1.1.1 version:
CMAC API:
     AES-128  16 48 16    410   0.410  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY:
     AES-128  16 48 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY adding EVP_MD_CTX_FLAG_FINALISE:
     AES-128  16 48 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e

The same with AESNI disabled:
CMAC API:
     AES-128  16 48 16    584   0.584  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY:
     AES-128  16 48 16    823   0.823  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY adding EVP_MD_CTX_FLAG_FINALISE:
     AES-128  16 48 16    387   0.387  475ac1c053379e7dbd4ce80b87d2178e

Now that a large fraction of the cost has been found, I can look
again to see where the biggest cost in 3.0 comes from now and if we
can do something about it.

I think changing the default is going to break applications, which
is what we want to avoid. I think we should document that this can
overhead can be large if you do small packets and that the
behavioru can be changed with that option.


Kurt


From openssl-users at dukhovni.org  Thu Jun 18 17:50:26 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 Jun 2020 13:50:26 -0400
Subject: problem with my code
In-Reply-To: <CAMYm8FpWO-SM_GLh97LtCfRETP_oM18P45hEL4R4cknPW4Po8Q@mail.gmail.com>
References: <CAMYm8FpWO-SM_GLh97LtCfRETP_oM18P45hEL4R4cknPW4Po8Q@mail.gmail.com>
Message-ID: <20200618175026.GS36399@straasha.imrryr.org>

On Thu, Jun 18, 2020 at 12:00:33PM +0200, Attila Csosz wrote:

>  err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));
> 
>  // Create SSL context
>  meth = SSLv23_server_method();

Have you tried SSLv23_client_method()?  Your application is a TLS
client, not a TLS server...

>  if (!meth) throw Exception("SSL: method");
>  ctx = SSL_CTX_new(meth);
>  if (!meth) throw Exception("SSL: context");
>  ssl = SSL_new(ctx);
>  if (!ssl) throw Exception("SSL: ssl");
>  SSL_set_fd(ssl, sd);
> 
>  // Connect
>  err = SSL_connect(ssl);
>  if (err == -1) throw Exception("SSL: SSL_connect");

-- 
    Viktor.

From matt at openssl.org  Thu Jun 18 18:01:15 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jun 2020 19:01:15 +0100
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
 <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
Message-ID: <6ee48dbb-383f-0822-3f7e-8d6a2f2becce@openssl.org>



On 18/06/2020 17:27, Ronny Meeus wrote:
> Op do 18 jun. 2020 om 18:13 schreef Salz, Rich <rsalz at akamai.com>:
>>
>>>    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
>>     BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
>>     should also be 4. If BN_BYTES is being incorrectly set to 8 on your
>>     platform then that would explain the discrepancy. Can you check?
>>
>> This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
>>
> 
> I used the following print statement so the sizeof is actual of the *d
> and not of the pointer :-).
> printf("BN_num data (size=%d top=%d neg=%d flags=%d, sizeof(*d)=%d)
> BN_BYTES=%d: ", rnd->dmax, rnd->top, rnd->neg, rnd->flags,
> sizeof(*rnd->d), BN_BYTES);
> 
> The output clearly shows that BN_BYTES is 8:
> 
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=8:
> efe838eb2cf627a7cf1944d5969e17602474f949d4e04f33263e49cdc9917b5f4f71f4f27eb06b2f41930dbac791ded7fae69fa604ec65686b412ef048e91cfd8c976e74ff237112406371b6cb2770588328f8db400718366665b6bca733a19c
> 
> I think we are getting close to the root-cause here ...

Ok, this is clearly why you're getting strange results. The question is
why is sizeof(*d) different to the value of BN_BYTES?

What Configure target did you use to build for this platform?

Also, take a look at the end of the file include/openssl/opensslconf.h

You should see a section at the end that looks like this:

/* Only one for the following should be defined */
# define SIXTY_FOUR_BIT_LONG
# undef SIXTY_FOUR_BIT
# undef THIRTY_TWO_BIT

This file is generated, and depending on what Configure has decided is
appropriate for your platform one of the above 3 should be defined, and
the other 2 undef'd. What does it show for your platform?

Matt


From ronny.meeus at gmail.com  Thu Jun 18 18:01:59 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 20:01:59 +0200
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
 <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
Message-ID: <CAMJ=MEcFNzEJi4xReiWvBhRVMqKO8s+0qRfa10Q_58re3CguBQ@mail.gmail.com>

Op do 18 jun. 2020 om 18:27 schreef Ronny Meeus <ronny.meeus at gmail.com>:
>
> Op do 18 jun. 2020 om 18:13 schreef Salz, Rich <rsalz at akamai.com>:
> >
> > >    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
> >     BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
> >     should also be 4. If BN_BYTES is being incorrectly set to 8 on your
> >     platform then that would explain the discrepancy. Can you check?
> >
> > This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
> >
>
> I used the following print statement so the sizeof is actual of the *d
> and not of the pointer :-).
> printf("BN_num data (size=%d top=%d neg=%d flags=%d, sizeof(*d)=%d)
> BN_BYTES=%d: ", rnd->dmax, rnd->top, rnd->neg, rnd->flags,
> sizeof(*rnd->d), BN_BYTES);
>
> The output clearly shows that BN_BYTES is 8:
>
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=8:
> efe838eb2cf627a7cf1944d5969e17602474f949d4e04f33263e49cdc9917b5f4f71f4f27eb06b2f41930dbac791ded7fae69fa604ec65686b412ef048e91cfd8c976e74ff237112406371b6cb2770588328f8db400718366665b6bca733a19c
>
> I think we are getting close to the root-cause here ...
>

I adapted the code so that the BN_BYTES is 4 in all cases (just a hack).
Now the issue is gone and the loop is not observed anymore but the
tool still fails to generate the keys:

LD_LIBRARY_PATH=/tmp ssh-keygen -A
ssh-keygen: generating new host keys: RSA

probable_prime 0 loop=0 again=0
bnrand bits=1536 top=1 bottom=1 bytes=192
data: db d2 2c 9e d8 99 08 af d0 f9 da 7c 19 2a 0d 05 94 e2 ba fd f5
60 38 74 81 aa 1a 1c cf 02 70 0d a6 97 51 c6 4a e4 13 98 39 99 7b c4
30 21 97 a0 32 89 3e 2c ff a2 fb 3f b3 bd f9 6b 59 00 f5 48 41 b7 57
cc a5 37 f9 d8 be ba f9 3d f0 6e 86 58 27 fb ae ca 9c 7b 2e 3f 4c 33
16 74 23 b0 c7 d7 74 19 8a ad 3e 5d 76 73 a5 f5 4a 95 d5 b0 da 5f a0
34 c8 ee 57 fb 88 22 be 5a f5 92 6e 47 08 68 e5 21 6c 57 b2 1b 1d 50
c9 89 d8 a3 76 24 b3 2d f3 b6 26 bc 35 33 b7 d0 73 09 8c 1b 2d 90 05
5a 75 24 05 1a de 04 31 ef 5b b1 55 62 33 86 8a 72 3d bc 5b c9 a1 55
e4 6a 4f cd 2e 28 5f 1a 09 25

probable_prime BN_num_bits=1536 bits=1536
BN_num data (size=48 top=48 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=4:
5f1a09734fcd2e28a155e46a3dbc5bc933868a725bb15562de0431ef7524051a2d90055a73098c1b3533b7d0f3b626bc7624b32dc989d8a3b21b1d50e5216c576e470868be5af59257fb8822a034c8eed5b0da5fa5f54a953e5d767374198aad23b0c7d74c3316749c7b2e3f27fbaecaf06e8658bebaf93da537f9d841b757cc5900f548b3bdf96bffa2fb3f32893e2c302197a039997bc44ae41398a69751c6cf02700d81aa1a1cf560387494e2bafd192a0d05d0f9da7cd89908afdbd22c9e

sshkey_generate failed: error in libcrypto
ssh-keygen: generating new host keys: DSA sshkey_generate failed:
error in libcrypto
ssh-keygen: generating new host keys: ECDSA sshkey_generate failed:
memory allocation failed
ssh-keygen: generating new host keys: ED25519

I also have the impression that it takes a very long time for the tool
to complete.
On other CPUs (ARM) the tool finishes much quicker (and successful).


> Ronny

From ronny.meeus at gmail.com  Thu Jun 18 18:33:22 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Thu, 18 Jun 2020 20:33:22 +0200
Subject: endless loop in probable_prime
In-Reply-To: <6ee48dbb-383f-0822-3f7e-8d6a2f2becce@openssl.org>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
 <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
 <6ee48dbb-383f-0822-3f7e-8d6a2f2becce@openssl.org>
Message-ID: <CAMJ=MEf-SVXTox=s6Hpsm3=UGHpMsbGya-Vnkrnk_is1PpN4_Q@mail.gmail.com>

Op do 18 jun. 2020 om 20:01 schreef Matt Caswell <matt at openssl.org>:
>
>
>
> On 18/06/2020 17:27, Ronny Meeus wrote:
> > Op do 18 jun. 2020 om 18:13 schreef Salz, Rich <rsalz at akamai.com>:
> >>
> >>>    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
> >>     BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
> >>     should also be 4. If BN_BYTES is being incorrectly set to 8 on your
> >>     platform then that would explain the discrepancy. Can you check?
> >>
> >> This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
> >>
> >
> > I used the following print statement so the sizeof is actual of the *d
> > and not of the pointer :-).
> > printf("BN_num data (size=%d top=%d neg=%d flags=%d, sizeof(*d)=%d)
> > BN_BYTES=%d: ", rnd->dmax, rnd->top, rnd->neg, rnd->flags,
> > sizeof(*rnd->d), BN_BYTES);
> >
> > The output clearly shows that BN_BYTES is 8:
> >
> > BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=8:
> > efe838eb2cf627a7cf1944d5969e17602474f949d4e04f33263e49cdc9917b5f4f71f4f27eb06b2f41930dbac791ded7fae69fa604ec65686b412ef048e91cfd8c976e74ff237112406371b6cb2770588328f8db400718366665b6bca733a19c
> >
> > I think we are getting close to the root-cause here ...
>
> Ok, this is clearly why you're getting strange results. The question is
> why is sizeof(*d) different to the value of BN_BYTES?
>
> What Configure target did you use to build for this platform?

We have identified the issue.
We use BR to compile our projects and it is a bug in the buildroot scripts.
This was the code before the patch
        default "linux-generic64 no-asm"        if BR2_ARCH_IS_64
        default "linux-generic32 no-asm"
resulting in the usage of the "linux-generic64 no-asm" target.

When change the above line in:
        default "linux-generic64 no-asm"        if BR2_ARCH_IS_64 &&
!BR2_MIPS_NABI32
        default "linux-generic32 no-asm"
the target becomes "linux-generic32 no-asm".

Compiling openssl with this solves the issue. We will deliver this
correction to the buildroot community.
Thanks all for the great support!


> Also, take a look at the end of the file include/openssl/opensslconf.h
>
> You should see a section at the end that looks like this:
>
> /* Only one for the following should be defined */
> # define SIXTY_FOUR_BIT_LONG
> # undef SIXTY_FOUR_BIT
> # undef THIRTY_TWO_BIT

For completeness, this was the section in the file:

/* Only one for the following should be defined */
# define SIXTY_FOUR_BIT_LONG
# undef SIXTY_FOUR_BIT
# undef THIRTY_TWO_BIT

> This file is generated, and depending on what Configure has decided is
> appropriate for your platform one of the above 3 should be defined, and
> the other 2 undef'd. What does it show for your platform?
>
> Matt
>

From kurt at roeckx.be  Thu Jun 18 19:18:05 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 18 Jun 2020 21:18:05 +0200
Subject: CMAC timings
In-Reply-To: <20200618172439.GA433646@roeckx.be>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
 <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
 <9F4FFBC1-4CA2-4E19-A955-5E46DB008EEB@ll.mit.edu>
 <20200618172439.GA433646@roeckx.be>
Message-ID: <20200618191805.GB433646@roeckx.be>

On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
> 
> Now that a large fraction of the cost has been found, I can look
> again to see where the biggest cost in 3.0 comes from now and if we
> can do something about it.

So a code path that I've noticed before when looking at the
profile is:
    /* TODO(3.0): Remove this eventually when no more legacy */
    if (ctx->op.sig.sigprovctx == NULL)
        return EVP_PKEY_CTX_ctrl(ctx, -1, EVP_PKEY_OP_TYPE_SIG,
                                 EVP_PKEY_CTRL_MD, 0, (void *)(md));

I think that is now actually causing most of the CPU usage.

This currently ends up doing an EVP_MAC_dup_ctx(), and I'm
currently not sure why, and what the effect is going to be
when sigprovctx != NULL. I think it might be better to wait until
someone fixes that before I look at that again.


Kurt


From ronny.meeus at gmail.com  Fri Jun 19 05:44:57 2020
From: ronny.meeus at gmail.com (Ronny Meeus)
Date: Fri, 19 Jun 2020 07:44:57 +0200
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEf-SVXTox=s6Hpsm3=UGHpMsbGya-Vnkrnk_is1PpN4_Q@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
 <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
 <6ee48dbb-383f-0822-3f7e-8d6a2f2becce@openssl.org>
 <CAMJ=MEf-SVXTox=s6Hpsm3=UGHpMsbGya-Vnkrnk_is1PpN4_Q@mail.gmail.com>
Message-ID: <CAMJ=MEepXCZz2_m12pCbNnraHh=Y5ZcFyatXrFtsXx7Aav5dtQ@mail.gmail.com>

Replying again since it looks like the final mail has not been
delivered to the newsgroup archive.
The issue has been found. It was a bug in buildroot passing the wrong target.

Op do 18 jun. 2020 om 20:33 schreef Ronny Meeus <ronny.meeus at gmail.com>:
>
> Op do 18 jun. 2020 om 20:01 schreef Matt Caswell <matt at openssl.org>:
> >
> >
> >
> > On 18/06/2020 17:27, Ronny Meeus wrote:
> > > Op do 18 jun. 2020 om 18:13 schreef Salz, Rich <rsalz at akamai.com>:
> > >>
> > >>>    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
> > >>     BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
> > >>     should also be 4. If BN_BYTES is being incorrectly set to 8 on your
> > >>     platform then that would explain the discrepancy. Can you check?
> > >>
> > >> This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
> > >>
> > >
> > > I used the following print statement so the sizeof is actual of the *d
> > > and not of the pointer :-).
> > > printf("BN_num data (size=%d top=%d neg=%d flags=%d, sizeof(*d)=%d)
> > > BN_BYTES=%d: ", rnd->dmax, rnd->top, rnd->neg, rnd->flags,
> > > sizeof(*rnd->d), BN_BYTES);
> > >
> > > The output clearly shows that BN_BYTES is 8:
> > >
> > > BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=8:
> > > efe838eb2cf627a7cf1944d5969e17602474f949d4e04f33263e49cdc9917b5f4f71f4f27eb06b2f41930dbac791ded7fae69fa604ec65686b412ef048e91cfd8c976e74ff237112406371b6cb2770588328f8db400718366665b6bca733a19c
> > >
> > > I think we are getting close to the root-cause here ...
> >
> > Ok, this is clearly why you're getting strange results. The question is
> > why is sizeof(*d) different to the value of BN_BYTES?
> >
> > What Configure target did you use to build for this platform?
>
> We have identified the issue.
> We use BR to compile our projects and it is a bug in the buildroot scripts.
> This was the code before the patch
>         default "linux-generic64 no-asm"        if BR2_ARCH_IS_64
>         default "linux-generic32 no-asm"
> resulting in the usage of the "linux-generic64 no-asm" target.
>
> When change the above line in:
>         default "linux-generic64 no-asm"        if BR2_ARCH_IS_64 &&
> !BR2_MIPS_NABI32
>         default "linux-generic32 no-asm"
> the target becomes "linux-generic32 no-asm".
>
> Compiling openssl with this solves the issue. We will deliver this
> correction to the buildroot community.
> Thanks all for the great support!
>
>
> > Also, take a look at the end of the file include/openssl/opensslconf.h
> >
> > You should see a section at the end that looks like this:
> >
> > /* Only one for the following should be defined */
> > # define SIXTY_FOUR_BIT_LONG
> > # undef SIXTY_FOUR_BIT
> > # undef THIRTY_TWO_BIT
>
> For completeness, this was the section in the file:
>
> /* Only one for the following should be defined */
> # define SIXTY_FOUR_BIT_LONG
> # undef SIXTY_FOUR_BIT
> # undef THIRTY_TWO_BIT
>
> > This file is generated, and depending on what Configure has decided is
> > appropriate for your platform one of the above 3 should be defined, and
> > the other 2 undef'd. What does it show for your platform?
> >
> > Matt
> >

From alpine.chappa at yandex.com  Fri Jun 19 06:21:13 2020
From: alpine.chappa at yandex.com (Eduardo Chappa)
Date: Fri, 19 Jun 2020 00:21:13 -0600 (MDT)
Subject: Signing with two different versions of Openssl
Message-ID: <alpine.LNX.2.23.453.2006190008580.23440@linux-aknz>

Dear all,

   I am trying to understand why the same code for the Alpine email program 
behave differently when compiling it with two different versions of 
Openssl. I have tried many variations of the official code, to no avail. 
Maybe here someone can point me in the right direction.

The git repository for the code is located at 
https://repo.or.cz/alpine.git

The code that creates detached signatures is in the file pith/smime.c. The 
flow more or less goes as follows

flags = PKCS7_DETACHED | PKCS7_PARTIAL;
if((p7 = PKCS7_sign(NULL, NULL, chain, in, flags)) != NULL
         && PKCS7_sign_add_signer(p7, pcert->cert, pcert->key, md, flags))
            PKCS7_final(p7, in, flags);
i2d_PKCS7_bio(out, p7);
(void) BIO_flush(out);

The "in" and "out" BIOs are memory buffers. The out BIO is internally 
base64 encoded and attached.

Does anyone here see why a code like this would succeed in creating valid 
signed messages when the same code in Alpine is built with version OpenSSL 
1.1.0i-fips 14 Aug 2018, but not with OpenSSL 1.1.1g 21 Apr 2020 (and I 
believe with any of the versions 1.1.1 series).

The exact details of the code are in the repository (address above) in the 
file pith/smime.c, starting around line 3766.

Thank you for any insights.

-- 
Eduardo

From matt at openssl.org  Fri Jun 19 08:48:26 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Jun 2020 09:48:26 +0100
Subject: CMAC timings
In-Reply-To: <20200618191805.GB433646@roeckx.be>
References: <levitte@openssl.org> <871rmgq52p.wl-levitte@openssl.org>
 <20200617105005.5A48140605C@ip-64-139-1-69.sjc.megapath.net>
 <20200617210254.GA380386@roeckx.be>
 <54c8e3411fcb57452bde7e567882b38e1e0559e4.camel@redhat.com>
 <9F4FFBC1-4CA2-4E19-A955-5E46DB008EEB@ll.mit.edu>
 <20200618172439.GA433646@roeckx.be> <20200618191805.GB433646@roeckx.be>
Message-ID: <ad01ae57-ce0c-31d4-f541-7fe3bfc97bed@openssl.org>



On 18/06/2020 20:18, Kurt Roeckx wrote:
> On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
>>
>> Now that a large fraction of the cost has been found, I can look
>> again to see where the biggest cost in 3.0 comes from now and if we
>> can do something about it.
> 
> So a code path that I've noticed before when looking at the
> profile is:
>     /* TODO(3.0): Remove this eventually when no more legacy */
>     if (ctx->op.sig.sigprovctx == NULL)
>         return EVP_PKEY_CTX_ctrl(ctx, -1, EVP_PKEY_OP_TYPE_SIG,
>                                  EVP_PKEY_CTRL_MD, 0, (void *)(md));
> 
> I think that is now actually causing most of the CPU usage.
> 
> This currently ends up doing an EVP_MAC_dup_ctx(), and I'm
> currently not sure why, and what the effect is going to be
> when sigprovctx != NULL. I think it might be better to wait until
> someone fixes that before I look at that again.

I looked into what was going on here.

The EVP_PKEY -> EVP_MAC bridge is implemented as a *legacy*
EVP_PKEY_METHOD, i.e. the conversion from EVP_PKEY -> EVP_MAC happens in
libcrypto *before* it hits any provider. So in the above code
"ctx->op.sig.signprovctx" will *always* be NULL because we are using the
bridge.

The answer to why we have the EVP_MAC_dup_ctx() lies in the
implementation of EVP_PKEY_new_CMAC_key(). In EVP_MAC terms the cipher
and key to be used are parameters set on an EVP_MAC_CTX - there is no
long term "key" object to store these in. By contrast an EVP_PKEY
considers these part of the long term "key" that can be reused in
multiple EVP_PKEY_CTX operations. To resolve this difference in approach
the EVP_PKEY -> MAC bridge creates an EVP_MAC_CTX during construction of
the EVP_PKEY and sets the cipher and key parameters on it. Then, every
time we do an EVP_DigestSignInit() call we create a new EVP_PKEY_CTX and
"dup" the EVP_MAC_CTX from the EVP_PKEY. In this way we can reuse the
same EVP_PKEY in many EVP_DigestSign*() operations.

That all seems to work but has the impact that if you only ever create
the EVP_PKEY, use it once and then throw it away then we have to create
the underlying EVP_MAC_CTX and then dup it (never actually using the
original EVP_MAC_CTX for anything other than a template for the
subsequent dup).

I find it slightly surprising that EVP_MAC_dup_ctx() is quite so
expensive. It mainly seems to end up doing a CMAC_CTX_copy() so I guess
this is where the time is going?

Matt

From matt at openssl.org  Fri Jun 19 09:43:27 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Jun 2020 10:43:27 +0100
Subject: endless loop in probable_prime
In-Reply-To: <CAMJ=MEepXCZz2_m12pCbNnraHh=Y5ZcFyatXrFtsXx7Aav5dtQ@mail.gmail.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
 <CAMJ=MEc2d7K0kXN9XgY+Ykkn5szLw63Y3V2t3NOjY3WAq595ng@mail.gmail.com>
 <6ee48dbb-383f-0822-3f7e-8d6a2f2becce@openssl.org>
 <CAMJ=MEf-SVXTox=s6Hpsm3=UGHpMsbGya-Vnkrnk_is1PpN4_Q@mail.gmail.com>
 <CAMJ=MEepXCZz2_m12pCbNnraHh=Y5ZcFyatXrFtsXx7Aav5dtQ@mail.gmail.com>
Message-ID: <3323be57-93e1-ecc9-935a-296ce8f15609@openssl.org>

Great - glad you found it.

Matt

On 19/06/2020 06:44, Ronny Meeus wrote:
> Replying again since it looks like the final mail has not been
> delivered to the newsgroup archive.
> The issue has been found. It was a bug in buildroot passing the wrong target.
> 
> Op do 18 jun. 2020 om 20:33 schreef Ronny Meeus <ronny.meeus at gmail.com>:
>>
>> Op do 18 jun. 2020 om 20:01 schreef Matt Caswell <matt at openssl.org>:
>>>
>>>
>>>
>>> On 18/06/2020 17:27, Ronny Meeus wrote:
>>>> Op do 18 jun. 2020 om 18:13 schreef Salz, Rich <rsalz at akamai.com>:
>>>>>
>>>>>>    BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
>>>>>     BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
>>>>>     should also be 4. If BN_BYTES is being incorrectly set to 8 on your
>>>>>     platform then that would explain the discrepancy. Can you check?
>>>>>
>>>>> This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
>>>>>
>>>>
>>>> I used the following print statement so the sizeof is actual of the *d
>>>> and not of the pointer :-).
>>>> printf("BN_num data (size=%d top=%d neg=%d flags=%d, sizeof(*d)=%d)
>>>> BN_BYTES=%d: ", rnd->dmax, rnd->top, rnd->neg, rnd->flags,
>>>> sizeof(*rnd->d), BN_BYTES);
>>>>
>>>> The output clearly shows that BN_BYTES is 8:
>>>>
>>>> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4) BN_BYTES=8:
>>>> efe838eb2cf627a7cf1944d5969e17602474f949d4e04f33263e49cdc9917b5f4f71f4f27eb06b2f41930dbac791ded7fae69fa604ec65686b412ef048e91cfd8c976e74ff237112406371b6cb2770588328f8db400718366665b6bca733a19c
>>>>
>>>> I think we are getting close to the root-cause here ...
>>>
>>> Ok, this is clearly why you're getting strange results. The question is
>>> why is sizeof(*d) different to the value of BN_BYTES?
>>>
>>> What Configure target did you use to build for this platform?
>>
>> We have identified the issue.
>> We use BR to compile our projects and it is a bug in the buildroot scripts.
>> This was the code before the patch
>>         default "linux-generic64 no-asm"        if BR2_ARCH_IS_64
>>         default "linux-generic32 no-asm"
>> resulting in the usage of the "linux-generic64 no-asm" target.
>>
>> When change the above line in:
>>         default "linux-generic64 no-asm"        if BR2_ARCH_IS_64 &&
>> !BR2_MIPS_NABI32
>>         default "linux-generic32 no-asm"
>> the target becomes "linux-generic32 no-asm".
>>
>> Compiling openssl with this solves the issue. We will deliver this
>> correction to the buildroot community.
>> Thanks all for the great support!
>>
>>
>>> Also, take a look at the end of the file include/openssl/opensslconf.h
>>>
>>> You should see a section at the end that looks like this:
>>>
>>> /* Only one for the following should be defined */
>>> # define SIXTY_FOUR_BIT_LONG
>>> # undef SIXTY_FOUR_BIT
>>> # undef THIRTY_TWO_BIT
>>
>> For completeness, this was the section in the file:
>>
>> /* Only one for the following should be defined */
>> # define SIXTY_FOUR_BIT_LONG
>> # undef SIXTY_FOUR_BIT
>> # undef THIRTY_TWO_BIT
>>
>>> This file is generated, and depending on what Configure has decided is
>>> appropriate for your platform one of the above 3 should be defined, and
>>> the other 2 undef'd. What does it show for your platform?
>>>
>>> Matt
>>>
> 

From michael at stroeder.com  Sat Jun 20 09:21:11 2020
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 20 Jun 2020 11:21:11 +0200
Subject: Multi-valued RDN in Subject Alternative Name extension
In-Reply-To: <CAOFedGwJvWS+6NPfcdvj=cbgAgawymkjGwgz39fLYhvmi3nSeA@mail.gmail.com>
References: <CAOFedGwJvWS+6NPfcdvj=cbgAgawymkjGwgz39fLYhvmi3nSeA@mail.gmail.com>
Message-ID: <230866ac-e199-c947-cfab-19f6c5cfc5b7@stroeder.com>

On 6/18/20 9:12 AM, Williams, Gareth wrote:
> I can successfully add a multi-value RDN to the Subject of a
> certificate request using the + format in the config file:
> [..]
> However, if I add a SAN to the request:
> [..]
> the resulting request has them as separate RDNs (as if the + is not
> noticed).
Probably not the answer you were expecting:

In general multi-valued RDNs are a can of worms. Even if you solve this
particular step within OpenSSL you might run into many more issues with
other components using the certs.

=> I'd strongly recommend to avoid multi-valued RDNs.

Sometimes people want to make the subject DN unique by adding attributes
to the RDN. But those attribute values would have to be unique in a
certain scope anyway to achieve that. C (country ISO code) does not look
like a good candiate for that. Or did you just use that as demo example?

Ciao, Michael.

From gareth at garethwilliams.me.uk  Sat Jun 20 10:11:24 2020
From: gareth at garethwilliams.me.uk (Williams, Gareth)
Date: Sat, 20 Jun 2020 11:11:24 +0100
Subject: Multi-valued RDN in Subject Alternative Name extension
In-Reply-To: <230866ac-e199-c947-cfab-19f6c5cfc5b7@stroeder.com>
References: <CAOFedGwJvWS+6NPfcdvj=cbgAgawymkjGwgz39fLYhvmi3nSeA@mail.gmail.com>
 <230866ac-e199-c947-cfab-19f6c5cfc5b7@stroeder.com>
Message-ID: <CAOFedGyyeTq1aJHwwB_2i8FkFBpX16ogPx+K2yerbm=1FoTYog@mail.gmail.com>

On Sat, 20 Jun 2020 at 10:21, Michael Str?der <michael at stroeder.com> wrote:
>
> On 6/18/20 9:12 AM, Williams, Gareth wrote:
> > I can successfully add a multi-value RDN to the Subject of a
> > certificate request using the + format in the config file:
> > [..]
> > However, if I add a SAN to the request:
> > [..]
> > the resulting request has them as separate RDNs (as if the + is not
> > noticed).
> Probably not the answer you were expecting:
>
> In general multi-valued RDNs are a can of worms. Even if you solve this
> particular step within OpenSSL you might run into many more issues with
> other components using the certs.
>
> => I'd strongly recommend to avoid multi-valued RDNs.
>
> Sometimes people want to make the subject DN unique by adding attributes
> to the RDN. But those attribute values would have to be unique in a
> certain scope anyway to achieve that. C (country ISO code) does not look
> like a good candiate for that. Or did you just use that as demo example?
>

Thanks for the response.

I chose the country attribute simply as an example.

I stumbled upon this while testing something else, so thought I?d ask
the question.  Your pragmatic answer is fine by me as I had no real
use case ? just a matter of curiosity.

Thanks again,

Gareth

From jb-openssl at wisemo.com  Sun Jun 21 14:22:34 2020
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Sun, 21 Jun 2020 16:22:34 +0200
Subject: freefunc - name clash with Python.h
In-Reply-To: <20200615073718.GX48101@straasha.imrryr.org>
References: <rsalz@akamai.com>
 <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
 <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
 <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>
 <20200615073718.GX48101@straasha.imrryr.org>
Message-ID: <6a1e95ab-c63d-fb3d-02cc-874cf8704376@wisemo.com>

On 2020-06-15 09:37, Viktor Dukhovni wrote:
> On Mon, Jun 15, 2020 at 06:07:20AM +0000, Jordan Brown wrote:
>> Supplying names for the arguments in function prototypes makes them
>> easier to read, but risks namespace problems.
> Yes, which I why, some time back, I argued unsuccessfuly that we SHOULD
> NOT use parameter names in public headers in OpenSSL, but sadly was not
> able to persuade a majority of the team.
>
> If this is ever reconsidered, my views have not changed.  OpenSSL SHOULD
> NOT include parameter names in public headers.
No sane compiler should complain about name clashes between unrelated
namespaces, such as between global type names and formal parameter names
in header function declarations (used exclusively for readable compiler
error messages about incorrect invocations).

Syntactically, the only case where there could be any overlap between
those two namespaces would be if the formal parameter names were not
preceded by type names, as might happen in K&R C.? The warnings leading
to this thread should be treated as a compiler bug, that should be easily
reproduced with short standalone (1 to 3 files) test samples submitted to
the relevant compiler bug tracker.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From jb-openssl at wisemo.com  Sun Jun 21 15:14:29 2020
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Sun, 21 Jun 2020 17:14:29 +0200
Subject: endless loop in probable_prime
In-Reply-To: <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
References: <CAMJ=MEd4tEdtWGUkiMETv_UBRRJGRKE9rH6COpuZnfc-Nvn=0Q@mail.gmail.com>
 <5d48dcf9-ca48-277b-66f6-b5c08d065a63@openssl.org>
 <CAMJ=MEfw=BzFQFy3T3Vf2o1e5gQqbOGmMKN9LeMCo=sG_o4L6A@mail.gmail.com>
 <27485cd4-c665-607b-25bf-15926224f386@openssl.org>
 <B745A822-8282-4880-AC6D-AE0CB0E010B9@akamai.com>
Message-ID: <8c8dcae3-d66b-8db8-a96b-31d141392816@wisemo.com>

On 2020-06-18 18:13, Salz, Rich via openssl-users wrote:
>>     BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
>      BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
>      should also be 4. If BN_BYTES is being incorrectly set to 8 on your
>      platform then that would explain the discrepancy. Can you check?
>
> This seems HIGHLY likely since Ronny said earlier that the same config/toolchain is used for 32bit userspace and 64bit kernel, right?
Maybe the internal headers should contain lines that abort compilation if
inconsistencies are found in the values provided by the (public or private)
headers.

For example, if BN_BYTES > sizeof(BN_ULONG), compilation should stop via
an abstraction over the presence/absence of the _Static_assert, 
static_assert
or macro emulation of same in any given compiler.

/* Something like this, but via a macro abstraction: */
#if (some C++ compilers)
 ? /* Works if? defined(__cplusplus) && __cplusplus >= 201103l */
 ? /* Works for clang++ if has_feature(cxx_static_assert) */
 ? /* Works for g++ >= 4.3.x if defined(__GXX_EXPERIMENTAL_CXX0X__) */
 ? /* Works for MSC++ >= 16.00 */
 ? /* Fails for g++ 4.7.x specifically */
 ? /* Fails for some versions of Apple XCode */
 ? static_assert(
 ??? (BN_BYTES <= sizeof(BN_ULONG)),
 ??? "Failed static assert: " "BN_BYTES <= sizeof(BN_ULONG)");
#elif (some C compilers)
 ? /* Works for clang with has_feature(c_static_assert) */
 ? /* Works for gcc >= 4.6.x */
 ? /* Fails for some versions of Apple XCode */
 ? _Static_assert(
 ? ? (BN_BYTES <= sizeof(BN_ULONG)),
 ??? "Failed static assert: " "BN_BYTES <= sizeof(BN_ULONG)");
#else
 ? /* Portable fallback, but some fudging may be needed for compilers
 ?? *??? without __COUNTER__ */
 ? /* If assertion fails, compiler will complain about invalid array size */
 ? /* If assertion is not a const expression, compiler will complain 
about that */
 ? typedef char OSSL_const_assert_##fudge##__LINE__##_##__COUNTER__[
 ??? (BN_BYTES <= sizeof(BN_ULONG)) ? 1 : -1];
#endif


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From openssl at jordan.maileater.net  Sun Jun 21 17:12:47 2020
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Sun, 21 Jun 2020 17:12:47 +0000
Subject: freefunc - name clash with Python.h
In-Reply-To: <6a1e95ab-c63d-fb3d-02cc-874cf8704376@wisemo.com>
References: <rsalz@akamai.com>
 <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
 <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
 <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>
 <20200615073718.GX48101@straasha.imrryr.org>
 <6a1e95ab-c63d-fb3d-02cc-874cf8704376@wisemo.com>
Message-ID: <01010172d7de45ac-832c2918-931f-43fe-afee-79ba977adb33-000000@us-west-2.amazonses.com>

On 6/21/2020 7:22 AM, Jakob Bohm via openssl-users wrote:
> No sane compiler should complain about name clashes between unrelated
> namespaces, such as between global type names and formal parameter names
> in header function declarations (used exclusively for readable compiler
> error messages about incorrect invocations).
>
> Syntactically, the only case where there could be any overlap between
> those two namespaces would be if the formal parameter names were not
> preceded by type names, as might happen in K&R C.? The warnings leading
> to this thread should be treated as a compiler bug, that should be easily
> reproduced with short standalone (1 to 3 files) test samples submitted to
> the relevant compiler bug tracker.

Macros can cause problems:

    #define??? foo??? 1
    [...]
    extern int func(int foo);

It works out that header files that want to be safe cannot use *any*
names that aren't reserved to them.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200621/23d6ad5b/attachment.html>

From dank at kegel.com  Sun Jun 21 17:20:54 2020
From: dank at kegel.com (Dan Kegel)
Date: Sun, 21 Jun 2020 10:20:54 -0700
Subject: freefunc - name clash with Python.h
In-Reply-To: <01010172d7de45ac-832c2918-931f-43fe-afee-79ba977adb33-000000@us-west-2.amazonses.com>
References: <rsalz@akamai.com>
 <CEA0AE6D-4A47-43EB-A78D-3D7CAF33E6C7@akamai.com>
 <20200614044619.DD28540605C@ip-64-139-1-69.sjc.megapath.net>
 <2f64302c62ac43018f8e486e0036aa57@Ex13.ncp.local>
 <01010172b696dfcc-a7728c1b-e192-4685-87ec-9b8343d6d931-000000@us-west-2.amazonses.com>
 <20200615073718.GX48101@straasha.imrryr.org>
 <6a1e95ab-c63d-fb3d-02cc-874cf8704376@wisemo.com>
 <01010172d7de45ac-832c2918-931f-43fe-afee-79ba977adb33-000000@us-west-2.amazonses.com>
Message-ID: <CAPF-yOaNf=3G-s4JG0i9=KEthwDJ9Ser1U09oajki8KOy7TuWg@mail.gmail.com>

On Sun, Jun 21, 2020 at 10:13 AM Jordan Brown
<openssl at jordan.maileater.net> wrote:
> It works out that header files that want to be safe cannot use *any* names that aren't reserved to them.

True that.

Openssl should probably stop using generic identifiers like freefunc
in its header files, out of sheer self-defense.
- Dan

From csosz77 at gmail.com  Mon Jun 22 13:17:41 2020
From: csosz77 at gmail.com (Attila Csosz)
Date: Mon, 22 Jun 2020 15:17:41 +0200
Subject: repetitive ssl send
Message-ID: <CAMYm8FofkAA745aRVH-jM7yEJ_03CL_PGhVYQAzrwkh_3Xz6eg@mail.gmail.com>

Hi,

I've a small C code and I can send and receive from google.
Here is the code

---------
char HEADERS[] = "GET /search?q=arduino HTTP/1.1\r\nHost:
www.google.com\r\nConnection:
close\r\n\r\n";
char HOST_NAME_PORT[] = "www.google.com:443";
const char* PREFERRED_CIPHERS =
"HIGH:!aNULL:!kRSA:!SRP:!PSK:!CAMELLIA:!RC4:!MD5:!DSS";

void init_openssl()
{
    SSL_load_error_strings();
    SSL_library_init();
}

void CreateSSL()
{
 // Create SSL context
 meth = SSLv23_client_method();
 if (!meth) throw Exception("SSL: method");

 ctx = SSL_CTX_new(meth);
 if (!ctx) throw Exception("SSL: SSL_CTX_new");

 old_opts = SSL_CTX_set_options(ctx, SSL_OP_ALL);

 web = BIO_new_ssl_connect(ctx);
 if (!web) throw Exception("SSL: BIO_new_ssl_connect");
}

void ConnectSSL()
{
 // Connect
 res = BIO_set_conn_hostname(web, HOST_NAME_PORT);
 if (!res) throw Exception("SSL: BIO_ctrl");

 res = BIO_get_ssl(web, &ssl);
 if (!res) throw Exception("SSL: BIO_ctrl");

 res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
 if (!res) throw Exception("SSL: SSL_set_cipher_list");

 res = BIO_do_connect(web);
 if (res <= 0) throw Exception("SSL: BIO_do_connect");

 res = BIO_do_handshake(web);
 if (res <= 0) throw Exception("SSL: BIO_do_handshake");
}

void SendSSL()
{
 // Send
 err = BIO_puts(web, HEADERS);
 if (err <= 0) throw Exception("SSL: BIO_puts");
}

void ReceiveSSL()
{
 // Read
 sResult = "";
 for (;;) {
  len = BIO_read(web, buf, sizeof(buf));
  sResult += buf;
  if (len <= 0)
   break;
 }
}

void TestProc()
{
 init_openssl();

 CreateSSL();
 ConnectSSL();
 SendSSL();
 ReceiveSSL();

 // Next request
 //

 lTmp = new TStringList;
 lTmp->Add(sResult);
 lTmp->SaveToFile("c:\\temp\\a1.htm");

 // Free
 BIO_free_all(web);
 EVP_cleanup();

}

---------
It is ok for one request.

My problem when I trying to send a new search request to google it works
only when I call
 CreateSSL();
 ConnectSSL();
again

so my new search request is
 CreateSSL();
 ConnectSSL();
 SendSSL();
 ReceiveSSL();

Is this normal?

When I trying to use
 SendSSL();
 ReceiveSSL();
only
I have got a page with errors (I think). The response is shorter, starts
with 0 (not with HTTP/1.1 200 OK)

What may the problem?


Thanks for your help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200622/42592ee3/attachment.html>

From shivakumar2696 at gmail.com  Mon Jun 22 15:45:18 2020
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Mon, 22 Jun 2020 21:15:18 +0530
Subject: x509_store_ctx_st structure in openssl 1.1.1
Message-ID: <CAN9sONfW=YUFOE=VodSuf37Ri4+=J=qQmMjKRbSPkq7SfACPwA@mail.gmail.com>

Hi,
I was using the structure
struct x509_store_ctx_st
provide by x509_vfy.h in openssl 1.0.2, but can you please help me on how
to use the same or alternative for the above structure on openssl 1.1.1


Thanks and regards
Shivakumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200622/1cd89913/attachment-0001.html>

From bill.c.roberts at gmail.com  Mon Jun 22 15:48:44 2020
From: bill.c.roberts at gmail.com (William Roberts)
Date: Mon, 22 Jun 2020 10:48:44 -0500
Subject: x509_store_ctx_st structure in openssl 1.1.1
In-Reply-To: <CAN9sONfW=YUFOE=VodSuf37Ri4+=J=qQmMjKRbSPkq7SfACPwA@mail.gmail.com>
References: <CAN9sONfW=YUFOE=VodSuf37Ri4+=J=qQmMjKRbSPkq7SfACPwA@mail.gmail.com>
Message-ID: <CAFftDdq3o216VN2vxP7YdyJrr9SJvtk+t2fPCKn_9+8fRSEHAw@mail.gmail.com>

On Mon, Jun 22, 2020 at 10:45 AM shiva kumar <shivakumar2696 at gmail.com> wrote:
>
> Hi,
> I was using the structure
> struct x509_store_ctx_st
> provide by x509_vfy.h in openssl 1.0.2, but can you please help me on how to use the same or alternative for the above structure on openssl 1.1.1

I think just use the accessor and getter methods provided by the same header:
X509_STORE_

>
>
> Thanks and regards
> Shivakumar

From martin.elshuber at theobroma-systems.com  Mon Jun 22 17:28:03 2020
From: martin.elshuber at theobroma-systems.com (Martin Elshuber)
Date: Mon, 22 Jun 2020 19:28:03 +0200
Subject: Record Layer Buffers & Zeroization
Message-ID: <df316ab4-3b28-01d6-658c-89c219b0e6dc@theobroma-systems.com>

Hi,

I have a question regarding the recordlayer and zeroization of plain
text data.

To my understanding openssl (I am on v1.1.1g) maintains inbound data for
TLS1.2 within
SSL.rlayer.rbuf.The data is split into records and the meta information
is kept in
SSL.rlayer.rrec. The data pointers isself alias SSS.rlayer.rbuf.

Decryption of inbound data is done in-place in ssl3_get_record(). So the
rbuf stores
(possibly sensitive) plaintext data until it is reused by followup data.

Is this correct?

I might be blind, but I just cannot find the location where this
plaintext data is
zeroized, neither by OPENSSL_cleanse() nor memset().

Am I blind, or is this just not done? Shouldn't there be a way to do
this just like
it is already done with keys?

The reasoning behind this, is that in some cases it might not only be
necessary to get
rid of keys when no longer used, but also to get rid of all residuals
transported over
the secure channel.

Note on outbound: In the outbound path, to my understanding no plaintext
copies are
created, since plain data only lives in the user buffer passed to
openssl. The user
has to take of this part.

Thx in advance & keep up your good work & kind regards
Martin




From openssl-users at dukhovni.org  Mon Jun 22 17:27:13 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Jun 2020 13:27:13 -0400
Subject: repetitive ssl send
In-Reply-To: <CAMYm8FofkAA745aRVH-jM7yEJ_03CL_PGhVYQAzrwkh_3Xz6eg@mail.gmail.com>
References: <CAMYm8FofkAA745aRVH-jM7yEJ_03CL_PGhVYQAzrwkh_3Xz6eg@mail.gmail.com>
Message-ID: <20200622172713.GU36399@straasha.imrryr.org>

On Mon, Jun 22, 2020 at 03:17:41PM +0200, Attila Csosz wrote:

> char HEADERS[] = "GET /search?q=arduino HTTP/1.1\r\nHost: www.google.com\r\nConnection: close\r\n\r\n";
> char HOST_NAME_PORT[] = "www.google.com:443";

Note the "Connection: close" in the HTTP request header!

> void init_openssl()
> {
>     SSL_load_error_strings();
>     SSL_library_init();
> }
> 
> void CreateSSL()
> {
>  // Create SSL context
>  meth = SSLv23_client_method();
>  if (!meth) throw Exception("SSL: method");
> 
>  ctx = SSL_CTX_new(meth);
>  if (!ctx) throw Exception("SSL: SSL_CTX_new");
>  old_opts = SSL_CTX_set_options(ctx, SSL_OP_ALL);

The SSL_CTX need only be created once, not once per connection.
You've made no provision for verifying the server certificate.
Typically you would load trusted CA certificate locations into
the SSL_CTX.

>  web = BIO_new_ssl_connect(ctx);
>  if (!web) throw Exception("SSL: BIO_new_ssl_connect");
> }

This code belows in the ConnectSSL function.

> 
> void ConnectSSL()
> {
>  // Connect
>  res = BIO_set_conn_hostname(web, HOST_NAME_PORT);
>  if (!res) throw Exception("SSL: BIO_ctrl");
> 
>  res = BIO_get_ssl(web, &ssl);
>  if (!res) throw Exception("SSL: BIO_ctrl");
> 
>  res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
>  if (!res) throw Exception("SSL: SSL_set_cipher_list");
> 
>  res = BIO_do_connect(web);
>  if (res <= 0) throw Exception("SSL: BIO_do_connect");
> 
>  res = BIO_do_handshake(web);
>  if (res <= 0) throw Exception("SSL: BIO_do_handshake");

This connection is unauthenticated.  Perhaps that's OK, but often it is
not.

> }
> 
> void SendSSL()
> {
>  // Send
>  err = BIO_puts(web, HEADERS);
>  if (err <= 0) throw Exception("SSL: BIO_puts");
> }
> 
> void ReceiveSSL()
> {
>  // Read
>  sResult = "";
>  for (;;) {
>   len = BIO_read(web, buf, sizeof(buf));
>   sResult += buf;
>   if (len <= 0)
>    break;
>  }

The server closes the connection after returning its reply.
You need to close the SSL BIO to avoid a memory leak.

> ---------
> It is ok for one request.
> 
> My problem when I trying to send a new search request to google it works
> only when I call
>  CreateSSL();
>  ConnectSSL();
> again

Naturally, you're not doing HTTP/1.1 connection keep-alive, and in any
case would need to be prepared for the server to close the connection
now and then.  You need an actual HTTPS library, naive open-coding of an
HTTP client over SSL is unlikely to be correct.  Something like libcurl
or similar is the way to go.

> What may the problem?

You're writing a na?ve HTTPS client from scratch.  A correct
implementation would understand "Content-Length" and chunked
trasfer encoding, handle server-initiated disconnects, be
prepared to receive multi-record responses, ...

-- 
    Viktor.

From shivaramakrishna.ch at gmail.com  Mon Jun 22 20:52:38 2020
From: shivaramakrishna.ch at gmail.com (shivaramakrishna chakravarthula)
Date: Mon, 22 Jun 2020 22:52:38 +0200
Subject: Compiling OpenSSL on Solaris sparcv9 using cc with FIPS support -
 Issues
Message-ID: <CAMYVo5PmvXU-b5wTT0L0MH_sLvWD7G0eYRiMVSiR=Wp2Fg7A7g@mail.gmail.com>

Hello,

I am trying to compile OpenSSL 1.0.2d with FIPS support on various Linux
and Unix platforms. I am building  "openssl-fips-ecp-2.0.16" prior to
building OpenSSL.

I have successfully compiled the same version of OpenSSL with FIPS support
in linux-x86_64, aix64-cc, solaris64-x86_64-cc architectures.  The build is
failing for "solaris64-sparcv9-cc" architecture.

See details below:


   - ./Configure solaris64-sparcv9-cc fips shared no-ec2m
   --with-fipsdir=/openssl-fips-ecp-2.0.16-build
   --prefix=/openssl-1.0.2d-build  -> Okay
   - make depend -> Okay
   - make -> *Fail*

/usr/ccs/bin/ranlib ../../libcrypto.a || echo Never mind.
> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
>         (cd ..; make libcrypto.so.1.0.0); \
> fi
> [ -z "libcrypto" ] || cc -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v9 -xO5
> -xstrconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_GF2m -I/openssl-fips-ecp-2.0.16-build/include -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -Iinclude \
>         -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso  \
>         /openssl-fips-ecp-2.0.16-build/lib/fips_premain.c
> /openssl-fips-ecp-2.0.16-build/lib/fipscanister.o \
>         libcrypto.a -lsocket -lnsl -ldl
> ld: fatal: symbol `_sparcv9_vis1_instrument_bus2' is multiply-defined:
>         (file /openssl-fips-ecp-2.0.16-build/lib/fipscanister.o type=FUNC;
> file libcrypto.a(sparccpuid.o) type=FUNC);
> ld: fatal: symbol `_sparcv9_vis1_instrument_bus' is multiply-defined:
>         (file /openssl-fips-ecp-2.0.16-build/lib/fipscanister.o type=FUNC;
> file libcrypto.a(sparccpuid.o) type=FUNC);
> ld: fatal: File processing errors. No output written to fips_premain_dso
> *** Error code 1
> make: Fatal error: Command failed for target `fips_premain_dso'
> Current working directory /openssl-1.0.2d
> *** Error code 1
> make: Fatal error: Command failed for target `shared'
> Current working directory /openssl-1.0.2d/crypto
> *** Error code 1
> The following command caused the error:
> dir=crypto; target=all; if expr " crypto ssl engines apps test tools " :
> ".* $dir " >/dev/null 2>&1; then  if [ -d "$dir" ]; then  (    cd $dir &&
> echo "making $target in $dir..." &&  TOP= && unset TOP ${LIB+LIB}
> ${LIBS+LIBS}        ${INCLUDE+INCLUDE} ${INCLUDES+INCLUDES}
> ${DIR+DIR} ${DIRS+DIRS} ${SRC+SRC}              ${LIBSRC+LIBSRC}
> ${LIBOBJ+LIBOBJ} ${ALL+ALL}    ${EXHEADER+EXHEADER} ${HEADER+HEADER}
>     ${GENERAL+GENERAL} ${CFLAGS+CFLAGS}             ${ASFLAGS+ASFLAGS}
> ${AFLAGS+AFLAGS}             ${LDCMD+LDCMD} ${LDFLAGS+LDFLAGS}
> ${SCRIPTS+SCRIPTS}    ${SHAREDCMD+SHAREDCMD} ${SHAREDFLAGS+SHAREDFLAGS}
>   ${SHARED_LIB+SHARED_LIB} ${LIBEXTRAS+LIBEXTRAS} && make -e
> PLATFORM='solaris64-sparcv9-cc' PROCESSOR=''  CC='cc' CFLAG='-KPIC
> -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
> -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
> -I/openssl-fips-ecp-2.0.16-build/include -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM'                       AS='cc'
> ASFLAG='-KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa
> -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
> -I/openssl-fips-ecp-2.0.16-build/include -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c'                    AR='ar
>  r' NM='nm' RANLIB='/usr/ccs/bin/ranlib'         CROSS_COMPILE=''
>  PERL='/usr/bin/perl' ENGDIRS='ccgost'           SDIRS='objects  md4 md5
> sha mdc2 hmac ripemd whrlpool  des aes rc2 rc4 idea bf cast camellia seed
> modes  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio stack lhash rand
> err  evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp ui krb5
>  cms pqueue ts srp cmac' LIBRPATH='/openssl-1.0.2d-build/lib'
> INSTALL_PREFIX=''               INSTALLTOP='/openssl-1.0.2d-build'
> OPENSSLDIR='/openssl-1.0.2d-build/ssl'       LIBDIR='lib'
>          MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD makedepend'
>  DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC2M
> -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE
> -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5
> -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_RSAX -DOPENSSL_NO_SCTP
> -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST'
> MAKEDEPPROG='makedepend'                        SHARED_LDFLAGS='-xarch=v9
> -G -dy -z text'               KRB5_INCLUDES='' LIBKRB5=''
> ZLIB_INCLUDE='' LIBZLIB=''      EXE_EXT='' SHARED_LIBS='libcrypto.so.1.0.0
> libssl.so.1.0.0'     SHLIB_EXT='.so.1.0.0' SHLIB_TARGET='solaris-shared'
>   PEX_LIBS='' EX_LIBS='-lsocket -lnsl -ldl'       CPUID_OBJ='sparcv9cap.o
> sparccpuid.o' BN_ASM='bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o
> vis3-mont.o sparct4-mont.o sparcv9-gf2m.o'    EC_ASM=''
> DES_ENC='des_enc-sparc.o fcrypt_b.o dest4-sparcv9.o'
>  AES_ENC='aes_core.o aes_cbc.o aes-sparcv9.o aest4-sparcv9.o'
> CMLL_ENC='camellia.o cmll_misc.o cmll_cbc.o cmllt4-sparcv9.o'
>  BF_ENC='bf_enc.o' CAST_ENC='c_enc.o'    RC4_ENC='rc4_enc.o rc4_skey.o'
> RC5_ENC='rc5_enc.o'      SHA1_ASM_OBJ='sha1-sparcv9.o sha256-sparcv9.o
> sha512-sparcv9.o'                         MD5_ASM_OBJ='md5-sparcv9.o'
>               RMD160_ASM_OBJ=''               WP_ASM_OBJ='wp_block.o'
>                   MODES_ASM_OBJ='ghash-sparcv9.o'
> ENGINES_ASM_OBJ=''              PERLASM_SCHEME='void'
> FIPSLIBDIR='/openssl-fips-ecp-2.0.16-build/lib/'
>  FIPSDIR='/openssl-fips-ecp-2.0.16-build'
>  FIPSCANLIB="${FIPSCANLIB:-libcrypto}"   THIS=${THIS:-build_crypto}
> MAKEFILE=Makefile MAKEOVERRIDES= TOP=.. DIR=$dir $target  ) || exit 1;  fi;
>  fi
> make: Fatal error: Command failed for target `build_crypto'


Can anyone please help me with a solution?

Machine Architecture details:

> bash-3.00# uname -a
> SunOS uspriu04 5.10 Generic sun4u sparc SUNW,Sun-Blade-100


Regards,
Shiva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200622/2c3b21f4/attachment-0001.html>

From matt at openssl.org  Tue Jun 23 10:19:19 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jun 2020 11:19:19 +0100
Subject: Record Layer Buffers & Zeroization
In-Reply-To: <df316ab4-3b28-01d6-658c-89c219b0e6dc@theobroma-systems.com>
References: <df316ab4-3b28-01d6-658c-89c219b0e6dc@theobroma-systems.com>
Message-ID: <0e787655-fe48-304d-6113-f9b7660c1bce@openssl.org>



On 22/06/2020 18:28, Martin Elshuber wrote:
> I might be blind, but I just cannot find the location where this
> plaintext data is
> zeroized, neither by OPENSSL_cleanse() nor memset().
> 
> Am I blind, or is this just not done? Shouldn't there be a way to do
> this just like
> it is already done with keys?

We don't currently do this. There would likely be some significant
performance impacts for doing this with all plaintext. That said it
might be a nice optional feature to add.

Matt

From martin.elshuber at theobroma-systems.com  Tue Jun 23 10:57:00 2020
From: martin.elshuber at theobroma-systems.com (Martin Elshuber)
Date: Tue, 23 Jun 2020 12:57:00 +0200
Subject: Record Layer Buffers & Zeroization
In-Reply-To: <0e787655-fe48-304d-6113-f9b7660c1bce@openssl.org>
References: <df316ab4-3b28-01d6-658c-89c219b0e6dc@theobroma-systems.com>
 <0e787655-fe48-304d-6113-f9b7660c1bce@openssl.org>
Message-ID: <4d54505a-0e98-c53c-01fb-6f392ef14415@theobroma-systems.com>

Thx for the answer,

than at least a can stop looking for this :).

And yes I can understand the performance hit and I agree that this
should be optional and disabled by default.

I am thinking of adding a OPENSSL_cleanse just ofter the memcpy in
ssl3_read_bytes. And probably replacing the OPENSSL_free by an
OPENSSL_clear_free in SSL3_BUFFER_release. The later gets rid of data
not yet deliverd to the application.

I am thinking to make both dependent on a flags such as
SSL_OP_CLEANSE_PLAINTEXT. But I am not sure how to select a suitable
bit, since all unused bits are currently stated to be reserved for
openssl 1.2.

Another option is to add a compiler option; Though I do not like this
too much.

Did I forget any locations where to more cleanses? Any other suggestions?

If you are still interested, I am happy to prepare a PR and move the
discussion there. I guess this is "CLA: trivial" patch anyways.

Martin

Am 23.06.2020 um 12:19 schrieb Matt Caswell:
>
> On 22/06/2020 18:28, Martin Elshuber wrote:
>> I might be blind, but I just cannot find the location where this
>> plaintext data is
>> zeroized, neither by OPENSSL_cleanse() nor memset().
>>
>> Am I blind, or is this just not done? Shouldn't there be a way to do
>> this just like
>> it is already done with keys?
> We don't currently do this. There would likely be some significant
> performance impacts for doing this with all plaintext. That said it
> might be a nice optional feature to add.
>
> Matt



From matt at openssl.org  Tue Jun 23 11:06:25 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jun 2020 12:06:25 +0100
Subject: Record Layer Buffers & Zeroization
In-Reply-To: <4d54505a-0e98-c53c-01fb-6f392ef14415@theobroma-systems.com>
References: <df316ab4-3b28-01d6-658c-89c219b0e6dc@theobroma-systems.com>
 <0e787655-fe48-304d-6113-f9b7660c1bce@openssl.org>
 <4d54505a-0e98-c53c-01fb-6f392ef14415@theobroma-systems.com>
Message-ID: <97f90e2a-8210-4d69-b7d0-76bccb6dae98@openssl.org>



On 23/06/2020 11:57, Martin Elshuber wrote:
> Thx for the answer,
> 
> than at least a can stop looking for this :).
> 
> And yes I can understand the performance hit and I agree that this
> should be optional and disabled by default.
> 
> I am thinking of adding a OPENSSL_cleanse just ofter the memcpy in
> ssl3_read_bytes. And probably replacing the OPENSSL_free by an
> OPENSSL_clear_free in SSL3_BUFFER_release. The later gets rid of data
> not yet deliverd to the application.
> 
> I am thinking to make both dependent on a flags such as
> SSL_OP_CLEANSE_PLAINTEXT. But I am not sure how to select a suitable
> bit, since all unused bits are currently stated to be reserved for
> openssl 1.2.

We don't allow features in stable branches, so this could only be
included in the forthcoming OpenSSL 3.0 (i.e the master branch). You can
use those reserved values there because we are not aiming for ABI
compatibility (only API).


> 
> Another option is to add a compiler option; Though I do not like this
> too much.
> 
> Did I forget any locations where to more cleanses? Any other suggestions?
> 
> If you are still interested, I am happy to prepare a PR and move the
> discussion there. I guess this is "CLA: trivial" patch anyways.

Please feel free to raise a PR - although this is unlikely to be CLA
trivial (we have a very high bar for something to be considered trivial).

Matt



> 
> Martin
> 
> Am 23.06.2020 um 12:19 schrieb Matt Caswell:
>>
>> On 22/06/2020 18:28, Martin Elshuber wrote:
>>> I might be blind, but I just cannot find the location where this
>>> plaintext data is
>>> zeroized, neither by OPENSSL_cleanse() nor memset().
>>>
>>> Am I blind, or is this just not done? Shouldn't there be a way to do
>>> this just like
>>> it is already done with keys?
>> We don't currently do this. There would likely be some significant
>> performance impacts for doing this with all plaintext. That said it
>> might be a nice optional feature to add.
>>
>> Matt
> 
> 

From csosz77 at gmail.com  Tue Jun 23 11:53:37 2020
From: csosz77 at gmail.com (Attila Csosz)
Date: Tue, 23 Jun 2020 13:53:37 +0200
Subject: repetitive ssl send
In-Reply-To: <20200622172713.GU36399@straasha.imrryr.org>
References: <CAMYm8FofkAA745aRVH-jM7yEJ_03CL_PGhVYQAzrwkh_3Xz6eg@mail.gmail.com>
 <20200622172713.GU36399@straasha.imrryr.org>
Message-ID: <CAMYm8FpZxgggHTH1Rb5KuVZWhLfxwmzKx3P4a2RuaxLhxGTxCg@mail.gmail.com>

I have a state machine with the following states: create, connect, send,
receive.

When the state sequence is the following: create, connect, send, receive
everything is ok (with my code, sent in the previous email). However when
there is a receive code after connect there is a problem. There is no data
after this receive phase (maybe is not problem) but after that: send
executed successfully and the receive returns with no data.

create
connect
receive : no data, maybe ok
send: ok
receive : no data here !!


create: calls CreateSSL
connect: calls ConnectSSL
send: calls SendSSL
receive: calls ReceiveSSL

What may the problem?

Attila



On Mon, Jun 22, 2020 at 7:35 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Mon, Jun 22, 2020 at 03:17:41PM +0200, Attila Csosz wrote:
>
> > char HEADERS[] = "GET /search?q=arduino HTTP/1.1\r\nHost: www.google.com\r\nConnection:
> close\r\n\r\n";
> > char HOST_NAME_PORT[] = "www.google.com:443";
>
> Note the "Connection: close" in the HTTP request header!
>
> > void init_openssl()
> > {
> >     SSL_load_error_strings();
> >     SSL_library_init();
> > }
> >
> > void CreateSSL()
> > {
> >  // Create SSL context
> >  meth = SSLv23_client_method();
> >  if (!meth) throw Exception("SSL: method");
> >
> >  ctx = SSL_CTX_new(meth);
> >  if (!ctx) throw Exception("SSL: SSL_CTX_new");
> >  old_opts = SSL_CTX_set_options(ctx, SSL_OP_ALL);
>
> The SSL_CTX need only be created once, not once per connection.
> You've made no provision for verifying the server certificate.
> Typically you would load trusted CA certificate locations into
> the SSL_CTX.
>
> >  web = BIO_new_ssl_connect(ctx);
> >  if (!web) throw Exception("SSL: BIO_new_ssl_connect");
> > }
>
> This code belows in the ConnectSSL function.
>
> >
> > void ConnectSSL()
> > {
> >  // Connect
> >  res = BIO_set_conn_hostname(web, HOST_NAME_PORT);
> >  if (!res) throw Exception("SSL: BIO_ctrl");
> >
> >  res = BIO_get_ssl(web, &ssl);
> >  if (!res) throw Exception("SSL: BIO_ctrl");
> >
> >  res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
> >  if (!res) throw Exception("SSL: SSL_set_cipher_list");
> >
> >  res = BIO_do_connect(web);
> >  if (res <= 0) throw Exception("SSL: BIO_do_connect");
> >
> >  res = BIO_do_handshake(web);
> >  if (res <= 0) throw Exception("SSL: BIO_do_handshake");
>
> This connection is unauthenticated.  Perhaps that's OK, but often it is
> not.
>
> > }
> >
> > void SendSSL()
> > {
> >  // Send
> >  err = BIO_puts(web, HEADERS);
> >  if (err <= 0) throw Exception("SSL: BIO_puts");
> > }
> >
> > void ReceiveSSL()
> > {
> >  // Read
> >  sResult = "";
> >  for (;;) {
> >   len = BIO_read(web, buf, sizeof(buf));
> >   sResult += buf;
> >   if (len <= 0)
> >    break;
> >  }
>
> The server closes the connection after returning its reply.
> You need to close the SSL BIO to avoid a memory leak.
>
> > ---------
> > It is ok for one request.
> >
> > My problem when I trying to send a new search request to google it works
> > only when I call
> >  CreateSSL();
> >  ConnectSSL();
> > again
>
> Naturally, you're not doing HTTP/1.1 connection keep-alive, and in any
> case would need to be prepared for the server to close the connection
> now and then.  You need an actual HTTPS library, naive open-coding of an
> HTTP client over SSL is unlikely to be correct.  Something like libcurl
> or similar is the way to go.
>
> > What may the problem?
>
> You're writing a na?ve HTTPS client from scratch.  A correct
> implementation would understand "Content-Length" and chunked
> trasfer encoding, handle server-initiated disconnects, be
> prepared to receive multi-record responses, ...
>
> --
>     Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200623/cd350791/attachment.html>

From bcloutier at integpg.com  Tue Jun 23 12:03:15 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Tue, 23 Jun 2020 08:03:15 -0400
Subject: server key exchange signature behavior
Message-ID: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>

Hello,

We administer a server (Windows) with a Bitnami stack for a Wordpress
implementation and that uses Apache Httpd and OpenSSL. Separately I am
developing the TLS ECC aspect of a controller device implementation and
note a problematic behavior with the server_key_exchange for ECDHE_RSA.
The developed device ECDHE_RSA suite works properly and as expected with
all of the other servers thus far tested. There is likely a
configuration issue with this Apache installation and I am fishing for a
hint.

The issue is that the RSA signature as part of the server_key_exchange
does not decrypt with the supplied certificate public RSA key. It does
indicate an rsa_pkcs1_sha256 signature.

With a fresh Bitnami install that still uses the default key and
certificate files, the protocol provides a valid digital signature. When
we change the server's certificate (and confirm this with the browser)
the server_key_exchange signature no longer validates. It is as if the
server continues to use the default key for the signature. I have not
tried to confirm that specific point.

My immediate question for someone close to the code is where does
Apache/OpenSSL look for the key file for this signature at this point in
the protocol?

I am hoping that there is just some additional configuration location
that needs to be given our new key file and/or certificate. Can anyone
confirm?

We noted this concern on a production server. We then installed the
stack on a different machine to confirm the fresh install operation. In
adding different key and certificate files we confirm that the signature
then fails. If I ignore the bad signature the secure communications
succeed.

I have been searching the net for this issue for weeks. That has been
fruitless. So I am turning to this list.

Bruce



-- 
Sent using Thunderbird on Ubuntu 16.04LTS




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200623/001df037/attachment-0001.sig>

From janjust at nikhef.nl  Tue Jun 23 18:57:25 2020
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 23 Jun 2020 20:57:25 +0200
Subject: server key exchange signature behavior
In-Reply-To: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
Message-ID: <cb4cde58-5b81-053d-11c1-65dbc22221e3@nikhef.nl>

Hi,

see comments/questions inline

On 23/06/20 14:03, Bruce Cloutier wrote:
> Hello,
>
> We administer a server (Windows) with a Bitnami stack for a Wordpress
> implementation and that uses Apache Httpd and OpenSSL. Separately I am
> developing the TLS ECC aspect of a controller device implementation and
> note a problematic behavior with the server_key_exchange for ECDHE_RSA.
> The developed device ECDHE_RSA suite works properly and as expected with
> all of the other servers thus far tested. There is likely a
> configuration issue with this Apache installation and I am fishing for a
> hint.
you mention TLS ECC, suggesting Elliptic Curve Crypto, which might 
indicate EC-encoded certificates as well, yet talk about ECDHE_RSA which 
is Elliptic-curve Diffie-Hellman Exchange with RSA? (for which you'd 
normally use RSA-encoded certificates.

Now you can use both with httpd+openssl but you do need to specify the 
right certificate (or certificates) when configuring mod_ssl - you can 
even concatenate the RSA-signed certificate and the EC-signed 
certificate in a single hostcert.pem and mod_ssl will pick up both , 
simply using


#?? Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.? If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.? Note that a kill -HUP will prompt again.? A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/httpd/certs/hostcert.pem

# ?? Server Private Key:
#?? If the key is not combined with the certificate, use this
#?? directive to point at the key file.? Keep in mind that if
#?? you've both a RSA and a DSA private key you can configure
#?? both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/certs/hostkey.pem


I'd recommend to take your test cert+key and see if you can run it using
 ? openssl s_server? <parms>
against
 ? openssl s_client <parms>

(use 'openssl s_server -help' and 'openssl s_client -help' for the 
parameter list).

If *that* works and apache+mod_ssl does not then you're looking at an 
mod_ssl configuration issue.

HTH,

JJK



> The issue is that the RSA signature as part of the server_key_exchange
> does not decrypt with the supplied certificate public RSA key. It does
> indicate an rsa_pkcs1_sha256 signature.
>
> With a fresh Bitnami install that still uses the default key and
> certificate files, the protocol provides a valid digital signature. When
> we change the server's certificate (and confirm this with the browser)
> the server_key_exchange signature no longer validates. It is as if the
> server continues to use the default key for the signature. I have not
> tried to confirm that specific point.
>
> My immediate question for someone close to the code is where does
> Apache/OpenSSL look for the key file for this signature at this point in
> the protocol?
>
> I am hoping that there is just some additional configuration location
> that needs to be given our new key file and/or certificate. Can anyone
> confirm?
>
> We noted this concern on a production server. We then installed the
> stack on a different machine to confirm the fresh install operation. In
> adding different key and certificate files we confirm that the signature
> then fails. If I ignore the bad signature the secure communications
> succeed.
>
> I have been searching the net for this issue for weeks. That has been
> fruitless. So I am turning to this list.
>
>


From kgoldman at us.ibm.com  Tue Jun 23 21:38:38 2020
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Tue, 23 Jun 2020 17:38:38 -0400
Subject: openssl with Rust
Message-ID: <rctsp0$2dv$1@ciao.gmane.io>

Environment is Windows, Visual Studio Code, the Shining Light openssl 
build and the openssl crate.

Does anyone have experience getting this to link?

Environment variables?
cargo.toml
anything else?


From levitte at openssl.org  Wed Jun 24 08:23:07 2020
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 24 Jun 2020 10:23:07 +0200
Subject: openssl with Rust
In-Reply-To: <rctsp0$2dv$1@ciao.gmane.io>
References: <rctsp0$2dv$1@ciao.gmane.io>
Message-ID: <87k0zwlvo4.wl-levitte@openssl.org>

I have very little knowledge of Rust...  however, there seems to exist
an openssl crate available already:  https://docs.rs/openssl/0.10.29/openssl/

Does that help?

Cheers,
Richard

On Tue, 23 Jun 2020 23:38:38 +0200,
Ken Goldman wrote:
> 
> Environment is Windows, Visual Studio Code, the Shining Light openssl
> build and the openssl crate.
> 
> Does anyone have experience getting this to link?
> 
> Environment variables?
> cargo.toml
> anything else?
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From abaci.mjm at gmail.com  Wed Jun 24 19:20:25 2020
From: abaci.mjm at gmail.com (Michael Mueller)
Date: Wed, 24 Jun 2020 15:20:25 -0400
Subject: Monolith compile verify.c
Message-ID: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>

I'm compiling verify.c as a monolith from 1.1.1g.

Using gcc 4.8.5 I have no problems.

Using gcc 4.3.4 I get a warning which we treat as an error:

gcc -c -Wall -Werror -Wextra -idirafter ../../inc -idirafter
../../../../OPENSSL/include/SUSE-Linux -DMONOLITH -DNO_ASN1_OLD -DLINUX -o
../../obj/verify.o ../../src/verify.c

cc1: warnings being treated as errors

../../src/verify.c:64: error: missing initializer

../../src/verify.c:64: error: (near initialization for
?verify_options[45].retval?)



I found the source of my problem and created a fix that I could toggle when
testing with different compilers. The fix compiles cleanly with both gcc
compilers mentioned above.

I have not tried it with Visual Studio yet.


const OPTIONS verify_options[] = {

    {OPT_HELP_STR, 1, '-', "Usage: %s [options] cert.pem...\n"},

    {OPT_HELP_STR, 1, '-', "Valid options are:\n"},

    {"help", OPT_HELP, '-', "Display this summary"},

    {"verbose", OPT_VERBOSE, '-',

        "Print extra information about the operations being performed."},

    {"CApath", OPT_CAPATH, '/', "A directory of trusted certificates"},

    {"CAfile", OPT_CAFILE, '<', "A file of trusted certificates"},

    {"no-CAfile", OPT_NOCAFILE, '-',

     "Do not load the default certificates file"},

    {"no-CApath", OPT_NOCAPATH, '-',

     "Do not load certificates from the default certificates directory"},

    {"untrusted", OPT_UNTRUSTED, '<', "A file of untrusted certificates"},

    {"trusted", OPT_TRUSTED, '<', "A file of trusted certificates"},

    {"CRLfile", OPT_CRLFILE, '<',

        "File containing one or more CRL's (in PEM format) to load"},

    {"crl_download", OPT_CRL_DOWNLOAD, '-',

        "Attempt to download CRL information for this certificate"},

    {"show_chain", OPT_SHOW_CHAIN, '-',

        "Display information about the certificate chain"},

    {"nameopt", OPT_NAMEOPT, 's', "Various certificate name options"},

    OPT_V_OPTIONS,

#ifndef OPENSSL_NO_ENGINE

    {"engine", OPT_ENGINE, 's', "Use engine, possibly a hardware device"},

#endif

#if 0

    {NULL, -1, 'Q', "unused end of list"} this is the change I?d like to
offer

#else

    {NULL} this is the current code

#endif

};


Questions

1. Is the fix valid?

2.  If fix is valid, what are the chances of getting the change accepted?

Thanks

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200624/6a486d15/attachment.html>

From rsalz at akamai.com  Wed Jun 24 19:24:03 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jun 2020 19:24:03 +0000
Subject: Monolith compile verify.c
In-Reply-To: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>
References: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>
Message-ID: <584E8D2C-1955-44BA-A79D-E7B139A97559@akamai.com>

C mandates that any ?missing? initializers are as if 0/null were present.


    {NULL, -1, 'Q', "unused end of list"} this is the change I?d like to offer



Turn off the warning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200624/03e6b37f/attachment-0001.html>

From matt at openssl.org  Thu Jun 25 09:50:31 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 25 Jun 2020 10:50:31 +0100
Subject: Monolith compile verify.c
In-Reply-To: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>
References: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>
Message-ID: <aa5dd518-3c6d-dfc9-6ce5-5dd744b7ece9@openssl.org>



On 24/06/2020 20:20, Michael Mueller wrote:
> 
> Questions
> 
> 1. Is the fix valid?

Seems ok, but it looks like the compiler warning is a bit over zealous.
We have the same pattern in many parts of the code I think without problems.

> 
> 2.? If fix is valid, what are the chances of getting the change accepted?

Doubtful.

Matt


From angus at magsys.co.uk  Thu Jun 25 10:15:00 2020
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Thu, 25 Jun 2020 11:15 +0100 (BST)
Subject: Unusual certificates
Message-ID: <memo.20200625111558.18844A@magsys.adsl.magsys.co.uk>

A client is having problems reading Polish Centum issued personal
certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
mostly.  

Using PEM_read_bio_X509 with some of these certificates says
error:00000000:lib(0):func(0):reason(0), while the X509 command line
tool says 'unable to load certificate'.  Some certificates work with
both methods.

Using the asn1parse command from any version of OpenSSL says 'Error:
offset out of range', while a Javascript based web tool is able to
decode the ASN1, but is perhaps more tolerant of errors.  

So it seems there is something in the creation of these certificates
that OpenSSL has never liked, but until 1.1.1 was tolerated
sufficiently to allow them to be read.  

This certificate reads OK in 1.1.1 but fails asn1parse:

-----BEGIN CERTIFICATE-----
MIIHXjCCBUagAwIBAgIIbBjyWVjJUvcwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAzMTkwODUxMDBaFw0yMTAz
MTgwODUxMDBaMGcxCzAJBgNVBAYTAlBMMREwDwYDVQQEDAhEWklFRFpJQzEPMA0G
A1UEKgwGUkFGQcWBMRowGAYDVQQFExFQTk9QTC03NDExMDMwMDQ3MTEYMBYGA1UE
AwwPUkFGQcWBIERaSUVEWklDMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAm94BNi+bv2+oUKzN27GV0+95sm1AuDKdiKw7M63HcnjL+YYLoQvhleD7KlZR
7ntZfJ05vpWpQWM0Pt54M1Y8sJQObg+tUDlulVi7nADOrUNb3Tgctq1vbou3OpIp
xaQUtC9qNpQbGXkgJRr09/nh5h09n4vgsvtS6cKlFfMe/o6xtUeWPYm+oVoAq5sG
in+aBSBdnd73v053kbdZcbDPXmOYuCr6O2MHi7p+McPg2KMJy+wfFX4SGSBJIAY2
Owt6mnIOCU6Y/dAUcbUDtNUTwq+gXL+zg7TdwkDDTohpnluNGfrYV5JYocHO63zo
3W/CyF/enCmNiC9QLakA22O04QIDAQABo4IC8jCCAu4wgdsGCCsGAQUFBwEDBIHO
MIHLMAgGBgQAjkYBATALBgYEAI5GAQMCAQowCAYGBACORgEEMHwGBgQAjkYBBTBy
MDYWMGh0dHA6Ly93d3cuc2lnaWxsdW0ucGwvcmVwb3p5dG9yaXVtL1FDQTFfUERT
LnBkZhMCRU4wOBYyaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0v
UUNBMV9QRFNQTC5wZGYTAlBMMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQEwEwYGBACO
RgEGMAkGBwQAjkYBBgEwcwYIKwYBBQUHAQEEZzBlMD4GCCsGAQUFBzAChjJodHRw
Oi8vcmVwby5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNlcjAj
BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2lnaWxsdW0ucGwwHQYDVR0OBBYEFDFY
5Q2FMMXaCpCyXFmUT2qgyA0JMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUQvpPhjaB
nSihni0atVC7qifynLQwgfkGA1UdIASB8TCB7jCB6wYKKoRoAYb4PQAAAzCB3DCB
2QYIKwYBBQUHAgIwgcwMgclLd2FsaWZpa293YW55IGNlcnR5ZmlrYXQgcG9kcGlz
dSBlbGVrdHJvbmljem5lZ28gcG93c3RhxYIgdyBvcGFyY2l1IG8gUG9saXR5a8SZ
IFVzxYJ1ZyBaYXVmYW5pYSBDVVogU2lnaWxsdW0uIFRyZcWbxIcgUG9saXR5a2kg
Q1VaIFNpZ2lsbHVtIHpuYWpkdWplIHNpxJkgcG9kIGFkcmVzZW0gaHR0cDovL3d3
dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0wQgYDVR0fBDswOTA3oDWgM4YxaHR0
cDovL2NybC5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNybDAO
BgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBACQ+ancYPWmfVDB/PTrV
D+nK8TX2HPcbgk/JrGJF0vaL+l9gTprg+3yMlfpcQfBXBsm7RwOEAK8LgaaFb7Ta
WPD1635RoGaIZ36k6WgENUjFjANya3RIRSzcOjgpeQWc6SeA++NJjQFNh7J73LMG
V5udFwpVug5yzP+LTlZZ/hoY2rN9xmY7QBn/cbgoNieRyUHbxq4zGifiJoVfKEiT
Fxl/CoUfnngxsVIsvgxFmGdnMT2j0oBODKoXJ1A8oJAcg8KnYTzI7Dnt3a5cGypv
n6V6tGv0IbHxdFu8nnsyNOSp1YhqTcfRzUGXf9NHyj6vyX4UR2ODJPccWC0uSufW
9KYio228yqj0IERG2mr8huJEBW/MEE3STmxT3R6a1OCAsVAPi3gL2yAXfn3Gdiam
MLhj/WO3OD9OyiHqTY6+/md4vOHkHy7GnKlYIJblddtziv8ek9uH/imbOQIKDjLN
Bvw3j9a55GHT/8+fow2vn31OmSfMWvikP4pntEvuMAwG2laTs19+gWdknt4Q3ma5
NTf9UnbQsFJAcW+gw3QWAmts5fZsQT806OyDvjt6jRlkmuIkeYRcYJ/E2Pg9oKx3
RiCIA1BQTImpYvbTJg9Q1DYQpbDGxDB9ENJDAyMNSIs85nBLvrri4rD6FC4Bz/m/
Og4GfIWH02DKEKBds/zPi+L5
-----END CERTIFICATE-----

This certificate can not be read in 1.1.1 but is OK in 1.1.0. 

-----BEGIN CERTIFICATE-----
MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
BcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAyM
jMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYDV
QQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQxH
zAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEBA
QUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNIU
f/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8mF
OeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vrP
+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCDg
aQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdRn
v/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB2
wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GA
QQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b
3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL
3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYHB
ACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYIK
wYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY
2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5wb
DAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNVH
SMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoqh
GgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vyd
HlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJja
XUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJlx
ZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRyZ
XNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8EO
zA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY
2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEAJ
fef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J5
LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQu
tizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t53
PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnGh
ws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5id
7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2G
5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFLS
t+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n3
YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn8
miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih/
CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls=
-----END CERTIFICATE-----

Is there a more tolerant way to read ASN1 than the asn1parse command? 

Angus











From hkario at redhat.com  Thu Jun 25 11:25:43 2020
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 25 Jun 2020 13:25:43 +0200
Subject: Unusual certificates
In-Reply-To: <memo.20200625111558.18844A@magsys.adsl.magsys.co.uk>
References: <memo.20200625111558.18844A@magsys.adsl.magsys.co.uk>
Message-ID: <49b7a40f-b17f-4a96-a4a8-b4748a48d0ef@redhat.com>

On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta Systems 
Ltd wrote:
> A client is having problems reading Polish Centum issued personal
> certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
> mostly.  
>
> Using PEM_read_bio_X509 with some of these certificates says
> error:00000000:lib(0):func(0):reason(0), while the X509 command line
> tool says 'unable to load certificate'.  Some certificates work with
> both methods.
>
> Using the asn1parse command from any version of OpenSSL says 'Error:
> offset out of range', while a Javascript based web tool is able to
> decode the ASN1, but is perhaps more tolerant of errors.  
>
> So it seems there is something in the creation of these certificates
> that OpenSSL has never liked, but until 1.1.1 was tolerated
> sufficiently to allow them to be read.  
>
> This certificate reads OK in 1.1.1 but fails asn1parse:

works just fine for me with 1.1.1g

> This certificate can not be read in 1.1.1 but is OK in 1.1.0. 
>

but this one fails parsing

>
> Is there a more tolerant way to read ASN1 than the asn1parse command? 

asn1parse expects BER encoding, that already is the most lenient, while
still standards-compliant, encoding that is supported.

Given that it errors out with
139628293990208:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:crypto/asn1/asn1_lib.c:91:
I'm guessing a mismatch between utf-8 and string encoding that makes
the lengths inconsistent. Some tools may just ignore them, but that doesn't
make the certificate well-formed.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic


From Michael.Wojcik at microfocus.com  Thu Jun 25 13:38:20 2020
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 25 Jun 2020 13:38:20 +0000
Subject: Monolith compile verify.c
In-Reply-To: <aa5dd518-3c6d-dfc9-6ce5-5dd744b7ece9@openssl.org>
References: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>
 <aa5dd518-3c6d-dfc9-6ce5-5dd744b7ece9@openssl.org>
Message-ID: <DM6PR18MB27004A98DB4CA873806F60ACF9920@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Matt Caswell
> Sent: Thursday, June 25, 2020 04:51
>
> On 24/06/2020 20:20, Michael Mueller wrote:
> >
> > Questions
> >
> > 1. Is the fix valid?
>
> Seems ok, but it looks like the compiler warning is a bit over zealous.

It's valid, but I'd argue it's not a "fix".

As Rich Salz pointed out, omitting initializers is permitted by the C standard. In fact it's endorsed, in the sense that the standard makes this behavior explicit (see e.g. ISO 9899-1999 6.7.8 #21 for arrays, or in the case of subobjects #19), and the Rationale (I'm referring to 5.10, published 2003) does not discourage its use, as it does for e.g. omitting braces for compound object initializers and relying on the mandated top-down-parse semantics.

In his monumental /The New C Standard: An Economic and Cultural Commentary/ (2005), Derek M. Jones comments on this aspect of the language by noting some costs involved in requiring all members be explicitly initialized, and concludes: " Given these costs and the fact that developers are generally aware of the default behavior, there does not appear to be a worthwhile benefit in a guideline recommending that the behavior be made explicit." (1669) The GCC developers (like all C implementors) would have done well to read Jones.

> We have the same pattern in many parts of the code I think without problems.

Yes, as it should be.

> > 2.  If fix is valid, what are the chances of getting the change accepted?
>
> Doubtful.

And I'd say that's appropriate. Some of the GCC developers would prefer programmers use a language which is similar to, but distinctly not C, eschewing useful constructs and employing various others which are not part of the C language. OpenSSL is written in C.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


From angus at magsys.co.uk  Thu Jun 25 13:59:00 2020
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Thu, 25 Jun 2020 14:59 +0100 (BST)
Subject: Unusual certificates
In-Reply-To: <memo.20200625111558.18844A@magsys.adsl.magsys.co.uk>
Message-ID: <memo.20200625145952.7260A@magsys.adsl.magsys.co.uk>

More information, the original certificates supplied by the end user
had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
email.  

If I try the asn1parse command on the wrapped certificates, they now
attempt to parse, the OK is fine, the bad one now gives an error
message from asn1parse:

Error in encoding
20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
long:crypto\asn1\asn1_lib.c:91:

and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
from PEM_read_bio_X509.  

The RFC says 'Parsers MAY handle other line sizes' but it would be good
if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
change my library code to check for line ending in the base64 to give
the user a polite message.  

Now the only problem is what is asn1 decoding unhappy with?

Angus



From openssl at openssl.org  Thu Jun 25 14:26:01 2020
From: openssl at openssl.org (OpenSSL)
Date: Thu, 25 Jun 2020 14:26:01 +0000
Subject: OpenSSL version 3.0.0-alpha4 published
Message-ID: <20200625142601.GA29824@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 3.0 alpha 4 released
   ====================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in alpha.

   OpenSSL 3.0 alpha 4 has now been made available.

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
   as known issues are available on the OpenSSL Wiki, here:

        https://wiki.openssl.org/index.php/OpenSSL_3.0

   The alpha release is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-3.0.0-alpha4.tar.gz
      Size: 13884897
      SHA1 checksum:  056194ea4ec57234ce3cb16b944d99c4d2a8b650
      SHA256 checksum:  d930b650e0899f5baca8b80c50e7401620c129fef6c50198400999776a39bd37

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.0.0-alpha4.tar.gz
    openssl sha256 openssl-3.0.0-alpha4.tar.gz

   Please download and check this alpha release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl70rYcACgkQ2cTSbQ5g
RJFWeAf/ZOGaHZbcAUy9Xm/R8x56qPJWD+3D8qGOgjNgKc/5r3kXII3I7NH7lc1j
zFSt/FA9NhqU7dIh/8/SlyZaBbFW/XZBRiczDqRSqAkAfsxhlj5tOq8xZoXuTqlN
it3DICC96jgh2xGo3LJUPgY1o0evsPLX98L/BtRZcZMcZed0ImZEEmJra3vEDr7H
C+Hu4/+gNDlAISDENSDygAE8vDB5hBDmk0YCySPKZpDbWPdV2/WF8oBlgRpNBjY+
zbk/V32xZkhf/x/nhRGNs44CJI8ymsDtp6UyV2e7ZW6LZNMGX7l0M8ZuJvLTFJJM
ZqQo7Xhn1EFdIRwTd+B2CvY2k73Pzw==
=khAk
-----END PGP SIGNATURE-----

From abaci.mjm at gmail.com  Thu Jun 25 14:31:42 2020
From: abaci.mjm at gmail.com (Michael Mueller)
Date: Thu, 25 Jun 2020 10:31:42 -0400
Subject: Monolith compile verify.c
In-Reply-To: <DM6PR18MB27004A98DB4CA873806F60ACF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <CAND81pEV5bfKKuK62nnBC=jfLM3G7Lin=f3OAPweBg51wxO4Qg@mail.gmail.com>
 <aa5dd518-3c6d-dfc9-6ce5-5dd744b7ece9@openssl.org>
 <DM6PR18MB27004A98DB4CA873806F60ACF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <CAND81pE=gsxMrHWJmq7k7Rdqu9xmdW9vKY-_DApDYp02YX7obg@mail.gmail.com>

Thank you so much for the replies. I appreciate the effort, time, and
detail.

Turns out the warning is created by:
-Wextra

Only occurs in the older compiler (which we are required to use).

Removing the compiler flag worked.

Thanks again,
Mike

On Thu, Jun 25, 2020, 9:42 AM Michael Wojcik <Michael.Wojcik at microfocus.com>
wrote:

> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of
> > Matt Caswell
> > Sent: Thursday, June 25, 2020 04:51
> >
> > On 24/06/2020 20:20, Michael Mueller wrote:
> > >
> > > Questions
> > >
> > > 1. Is the fix valid?
> >
> > Seems ok, but it looks like the compiler warning is a bit over zealous.
>
> It's valid, but I'd argue it's not a "fix".
>
> As Rich Salz pointed out, omitting initializers is permitted by the C
> standard. In fact it's endorsed, in the sense that the standard makes this
> behavior explicit (see e.g. ISO 9899-1999 6.7.8 #21 for arrays, or in the
> case of subobjects #19), and the Rationale (I'm referring to 5.10,
> published 2003) does not discourage its use, as it does for e.g. omitting
> braces for compound object initializers and relying on the mandated
> top-down-parse semantics.
>
> In his monumental /The New C Standard: An Economic and Cultural
> Commentary/ (2005), Derek M. Jones comments on this aspect of the language
> by noting some costs involved in requiring all members be explicitly
> initialized, and concludes: " Given these costs and the fact that
> developers are generally aware of the default behavior, there does not
> appear to be a worthwhile benefit in a guideline recommending that the
> behavior be made explicit." (1669) The GCC developers (like all C
> implementors) would have done well to read Jones.
>
> > We have the same pattern in many parts of the code I think without
> problems.
>
> Yes, as it should be.
>
> > > 2.  If fix is valid, what are the chances of getting the change
> accepted?
> >
> > Doubtful.
>
> And I'd say that's appropriate. Some of the GCC developers would prefer
> programmers use a language which is similar to, but distinctly not C,
> eschewing useful constructs and employing various others which are not part
> of the C language. OpenSSL is written in C.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/424ba7eb/attachment.html>

From Erwann.Abalea at docusign.com  Thu Jun 25 14:40:26 2020
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 25 Jun 2020 14:40:26 +0000
Subject: [EXTERNAL] Re: Unusual certificates
In-Reply-To: <memo.20200625145952.7260A@magsys.adsl.magsys.co.uk>
References: <memo.20200625111558.18844A@magsys.adsl.magsys.co.uk>
 <memo.20200625145952.7260A@magsys.adsl.magsys.co.uk>
Message-ID: <05684C62-941F-4E9C-9D3F-E71D625BA7E1@docusign.com>

The second certificate seems garbaged at the 4th RDN of the issuerName.
The Base64 edition might have added or deleted some characters.

Cordialement,
Erwann Abalea

?Le 25/06/2020 16:00, ? openssl-users au nom de Angus Robertson - Magenta Systems Ltd ? <openssl-users-bounces at openssl.org au nom de angus at magsys.co.uk> a ?crit :

    More information, the original certificates supplied by the end user
    had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
    email.  

    If I try the asn1parse command on the wrapped certificates, they now
    attempt to parse, the OK is fine, the bad one now gives an error
    message from asn1parse:

    Error in encoding
    20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
    long:crypto\asn1\asn1_lib.c:91:

    and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
    from PEM_read_bio_X509.  

    The RFC says 'Parsers MAY handle other line sizes' but it would be good
    if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
    change my library code to check for line ending in the base64 to give
    the user a polite message.  

    Now the only problem is what is asn1 decoding unhappy with?

    Angus




From jan.m.danielsson at gmail.com  Thu Jun 25 14:52:27 2020
From: jan.m.danielsson at gmail.com (Jan Danielsson)
Date: Thu, 25 Jun 2020 16:52:27 +0200
Subject: openssl with Rust
In-Reply-To: <87k0zwlvo4.wl-levitte@openssl.org>
References: <rctsp0$2dv$1@ciao.gmane.io> <87k0zwlvo4.wl-levitte@openssl.org>
Message-ID: <e6a4307a-9825-5be2-e806-53a366827cfd@gmail.com>

On 2020-06-24 10:23, Richard Levitte wrote:
> I have very little knowledge of Rust...  however, there seems to exist
> an openssl crate available already:  https://docs.rs/openssl/0.10.29/openssl/
> 
> Does that help?

   The OP mentioned using "the openssl crate", so I don't think that's
the problem.

   This is kind of a known issue.  On unixy platforms there are plenty
of common, known, ways to find libraries and headers (common locations,
pkg-config, etc).  Windows have no such common mechanisms[*].

   Some crate developers are aware of these issues so they support
building a static library stored locally for the crate.  For instance,
rusqlite supports building its own sqlite3 library, which helps a lot on
Windows.  The problem with OpenSSL is that the build system needs perl.
 This could in theory be solved by build.rs downloading a portable
version of perl, etc.

   Anyway -- this is an openssl crate issue, and not related to the
openssl project itself.


   But I will add:  I suspect the openssl project will be getting more
and more questions about the openssl Rust crate.  Probably a good idea
to have a nice copy/paste reply ready.  And regarding this:


   [*] There is one potential solution to this: vcpkg.  Some crates try
to use vcpkg to find dependencies.  I suggest the OP checks into whether
building openssl with vcpkg will help.  (The openssl crate would need to
be one of the crates that actually supports vcpkg, and I'm unsure if
that is the case.  If it isn't then someone should probably file an
issue with the crate owner about that).



> 
> Cheers,
> Richard
> 
> On Tue, 23 Jun 2020 23:38:38 +0200,
> Ken Goldman wrote:
>>
>> Environment is Windows, Visual Studio Code, the Shining Light openssl
>> build and the openssl crate.
>>
>> Does anyone have experience getting this to link?
>>
>> Environment variables?
>> cargo.toml
>> anything else?
>>


-- 
Kind Regards,
Jan

From jb-openssl at wisemo.com  Thu Jun 25 15:01:57 2020
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 25 Jun 2020 17:01:57 +0200
Subject: Unusual certificates
In-Reply-To: <49b7a40f-b17f-4a96-a4a8-b4748a48d0ef@redhat.com>
References: <memo.20200625111558.18844A@magsys.adsl.magsys.co.uk>
 <49b7a40f-b17f-4a96-a4a8-b4748a48d0ef@redhat.com>
Message-ID: <5848e698-54a9-7ca3-ad71-9519894b3ea6@wisemo.com>

On 2020-06-25 13:25, Hubert Kario wrote:
> On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta 
> Systems Ltd wrote:
>> A client is having problems reading Polish Centum issued personal
>> certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
>> mostly.
>> Using PEM_read_bio_X509 with some of these certificates says
>> error:00000000:lib(0):func(0):reason(0), while the X509 command line
>> tool says 'unable to load certificate'.? Some certificates work with
>> both methods.
>>
>> Using the asn1parse command from any version of OpenSSL says 'Error:
>> offset out of range', while a Javascript based web tool is able to
>> decode the ASN1, but is perhaps more tolerant of errors.
>> So it seems there is something in the creation of these certificates
>> that OpenSSL has never liked, but until 1.1.1 was tolerated
>> sufficiently to allow them to be read.
>> This certificate reads OK in 1.1.1 but fails asn1parse:
>
> works just fine for me with 1.1.1g
>
>> This certificate can not be read in 1.1.1 but is OK in 1.1.0.
>
> but this one fails parsing
>
>>
>> Is there a more tolerant way to read ASN1 than the asn1parse command? 
>
> asn1parse expects BER encoding, that already is the most lenient, while
> still standards-compliant, encoding that is supported.
>
> Given that it errors out with
> 139628293990208:error:0D07209B:asn1 encoding 
> routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91:
> I'm guessing a mismatch between utf-8 and string encoding that makes
> the lengths inconsistent. Some tools may just ignore them, but that 
> doesn't
> make the certificate well-formed.
I have tried examining these two certificates with Peter Gutmann's 
dumpasn1.c
and a generic hex dumper.

For the second certificate, dumpasn1.c complains about a badly encoded 
SET at
file offset 0x8E (after Base64 decoding):

0008E?????????????????????????????????????????? 31 19
00090 05 c1 80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c
000A0 8d 4c 0c 0c 0c 4c 0e 4c 0c
000A9 ? ? ? ? ? ? ? ? ? ? ? ? ?? 07 85 c3 4c 4e 4c 0c

My manual attempt to recover from this results in the following
further failures:

Attempt1: Straight BER/DER:
SET {
 ? NULL-object of a very huge length: The number of bytes is
 ? ? 0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
 ? ? ? 0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
 ? ? ? 0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
 ? ? ? 8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
 ? ? ? 01
 ??? -- ERROR: This runs beyond end-of-file
 ??? -- ERROR: This runs beyond end-of-SET (0x19 bytes)
}

Attempt2: Assume length byte for zero length NULL object omitted:
SET { NULL-object with missing length-encoding of its zero length
 ????? private-tag-1 object with indefinite length
 ??? -- ERROR: This runs beyond end-of-SET (0x19 bytes)
}

Attempt3: Treat SET as an opaque blob
SET { -- Contents ignored }
ObjectDescriptor of length 0x151CC bytes
 ? -- ERROR: This runs beyond end-of-file

Attempt4: Treat preceding string as encoded with length 1 too small
SET {
 ? SEQUENCE {
 ??? OBJECT IDENTIFIER commonName -- 2.5.4.3
 ??? UTF8String 'CUZ Sigillum - QCA11'
 ? ? ? -- WARNING: One byte beyond declared length of containing SEQUENCE
 ? }
 ? ? -- WARNING: One byte beyond declared length of containing SET
}
GraphicString '\c1\80\d5\41\18'
Application-tag-3 object of length 4 bytes: 0x15 90 55 14
PrintableString 4d 4c 8d 4c 0c 0c 0c 4c 0e 4c 0c
 ? -- WARNING: Bad characters
ObjectDescriptor of length 0x151CC bytes
 ? -- ERROR: This runs beyond end-of-file
 ? -- WARNING: This runs beyond length of containing DN (0x80 bytes)

Attempt5: Treat preceding string as encoded with length 2 too small
SET {
 ? SEQUENCE {
 ??? OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11\19'
 ? ? ? -- WARNING: 2 bytes beyond declared length of containing SEQUENCE
 ? }
 ? ? -- WARNING: 2 bytes beyond declared length of containing SET
 ?}
NULL-object of a very huge length: The number of bytes is
 ? 0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
 ??? 0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
 ??? 0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
 ??? 8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
 ??? 01
 ? -- ERROR: This runs beyond end-of-file
 ? -- WARNING: This runs beyond length of containing DN (0x80 bytes)

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From bcloutier at integpg.com  Thu Jun 25 15:10:58 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Thu, 25 Jun 2020 11:10:58 -0400
Subject: server key exchange signature behavior
In-Reply-To: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
Message-ID: <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>

Has anyone thought about this question? The site is https://jnior.com if
anyone wants to hit it. For me the digital signature in the
server_key_exchange does not verify. Is there a site diagnostic that
might report on this? I suspect that we have not fully configured the
change in certificates. Has us stumped. Could really use a hint.

On 6/23/20 8:03 AM, Bruce Cloutier wrote:
> Hello,
>
> We administer a server (Windows) with a Bitnami stack for a Wordpress
> implementation and that uses Apache Httpd and OpenSSL. Separately I am
> developing the TLS ECC aspect of a controller device implementation and
> note a problematic behavior with the server_key_exchange for ECDHE_RSA.
> The developed device ECDHE_RSA suite works properly and as expected with
> all of the other servers thus far tested. There is likely a
> configuration issue with this Apache installation and I am fishing for a
> hint.
>
> The issue is that the RSA signature as part of the server_key_exchange
> does not decrypt with the supplied certificate public RSA key. It does
> indicate an rsa_pkcs1_sha256 signature.
>
> With a fresh Bitnami install that still uses the default key and
> certificate files, the protocol provides a valid digital signature. When
> we change the server's certificate (and confirm this with the browser)
> the server_key_exchange signature no longer validates. It is as if the
> server continues to use the default key for the signature. I have not
> tried to confirm that specific point.
>
> My immediate question for someone close to the code is where does
> Apache/OpenSSL look for the key file for this signature at this point in
> the protocol?
>
> I am hoping that there is just some additional configuration location
> that needs to be given our new key file and/or certificate. Can anyone
> confirm?
>
> We noted this concern on a production server. We then installed the
> stack on a different machine to confirm the fresh install operation. In
> adding different key and certificate files we confirm that the signature
> then fails. If I ignore the bad signature the secure communications
> succeed.
>
> I have been searching the net for this issue for weeks. That has been
> fruitless. So I am turning to this list.
>
> Bruce
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/922b629c/attachment.sig>

From tom.browder at gmail.com  Thu Jun 25 15:14:05 2020
From: tom.browder at gmail.com (Tom Browder)
Date: Thu, 25 Jun 2020 10:14:05 -0500
Subject: Private CA client cert file for iPad for a website
Message-ID: <CAFMGiz9M0XSCfUXC_8b2s7Av7LYv348VzOsYQ=V7vrHFBnO5QA@mail.gmail.com>

Can anyone tell me how to generate an acceptable client cert for an iPad?

I have so far been unable to find out the file format needed.

I generated client cert files for my classmates over seven years ago in p12
format and they still work fine on Linux, Mac, and Windows devices but I
want to (1) update all certs to modern standards and (2) add usable certs
for iOS and android devices as well as the existing format.

I am currently running OpenSSL 1.1.1g on Debian Buster.

Any help would be appreciated.

Blessings,

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/da200cea/attachment.html>

From dirkx at webweaving.org  Thu Jun 25 15:15:38 2020
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Thu, 25 Jun 2020 17:15:38 +0200
Subject: Private CA client cert file for iPad for a website
In-Reply-To: <CAFMGiz9M0XSCfUXC_8b2s7Av7LYv348VzOsYQ=V7vrHFBnO5QA@mail.gmail.com>
References: <CAFMGiz9M0XSCfUXC_8b2s7Av7LYv348VzOsYQ=V7vrHFBnO5QA@mail.gmail.com>
Message-ID: <8C1DAB17-86DB-421A-9016-654F17ACBEBA@webweaving.org>

On 25 Jun 2020, at 17:14, Tom Browder <tom.browder at gmail.com> wrote:

> Can anyone tell me how to generate an acceptable client cert for an iPad?
> 
> I have so far been unable to find out the file format needed.
> 
> I generated client cert files for my classmates over seven years ago in p12 format and they still work fine on Linux, Mac, and Windows devices but I want to (1) update all certs to modern standards and (2) add usable certs for iOS and android devices as well as the existing format.
> 
> I am currently running OpenSSL 1.1.1g on Debian Buster.

Have a play with https://interop.redwax.eu/rs/scep/

Dw.


From angus at magsys.co.uk  Thu Jun 25 15:30:00 2020
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Thu, 25 Jun 2020 16:30 +0100 (BST)
Subject: [EXTERNAL] Re: Unusual certificates
In-Reply-To: <05684C62-941F-4E9C-9D3F-E71D625BA7E1@docusign.com>
Message-ID: <memo.20200625163008.11424C@magsys.adsl.magsys.co.uk>

> The second certificate seems garbaged at the 4th RDN of the 
> issuerName.
> The Base64 edition might have added or deleted some characters.

Sorry, looks like my manual word wrapping lost a character: 

-----BEGIN CERTIFICATE-----
MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAy
MjMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYD
VQQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQx
HzAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNI
Uf/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8m
FOeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vr
P+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCD
gaQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdR
nv/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB
2wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5G
AQQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0
b3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBs
L3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYH
BACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYI
KwYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x
Y2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5w
bDAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNV
HSMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoq
hGgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vy
dHlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJj
aXUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJl
xZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRy
ZXNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8E
OzA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x
Y2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEA
Jfef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J
5LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQ
utizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t5
3PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnG
hws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5i
d7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2
G5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFL
St+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n
3YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn
8miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih
/CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls=
-----END CERTIFICATE-----


This now reads correctly with OpenSSL.  So the real error here was that
sometimes OpenSSL accepts unwrapped base64, and sometimes not, but
asn1parse never accepts it. 

Angus




From Michael.Wojcik at microfocus.com  Thu Jun 25 16:07:07 2020
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 25 Jun 2020 16:07:07 +0000
Subject: server key exchange signature behavior
In-Reply-To: <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
Message-ID: <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Bruce Cloutier
> Sent: Thursday, June 25, 2020 10:11
>
> Has anyone thought about this question?

From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)

> The site is https://jnior.com if
> anyone wants to hit it. For me the digital signature in the
> server_key_exchange does not verify.

I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From mhkelley2017 at gmail.com  Thu Jun 25 16:54:05 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Thu, 25 Jun 2020 10:54:05 -0600
Subject: Error building OpenSSL-1.1.1g
Message-ID: <022a01d64b11$3d237730$b76a6590$@gmail.com>

Error:  'ml64' is not recognized as an internal or external command,

operable program or batch file.

 

Platform: Windows 10

Intended context for use: Mingw-64, Qt 5.15

Building with Visual Studio  2019 Community

Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

 

Configuration commands:

perl Configure VC-WIN64A-masm --prefix=%PREFIX%

 

Error output:

 

cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "."
/I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
"crypto\aes\aes_wrap.c" 2>&1 > crypto\aes\aes_wrap.d

        set ASM=ml64

        "C:\Perl64\bin\perl.exe" "crypto\aes\asm\aesni-mb-x86_64.pl" masm
crypto\aes\aesni-mb-x86_64.asm

        ml64  /c /Cp /Cx /nologo /Zi /Focrypto\aes\aesni-mb-x86_64.obj
"crypto\aes\aesni-mb-x86_64.asm"

'ml64' is not recognized as an internal or external command,

operable program or batch file.

NMAKE : fatal error U1077: 'ml64' : return code '0x1'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
: return code '0x2'

Stop.

 

Initial build output:

 

Configuring OpenSSL version 1.1.1g (0x1010107fL) for VC-WIN64A-masm

Using os-specific seed configuration

Creating configdata.pm

Creating makefile

 

**********************************************************************

***                                                                ***

***   OpenSSL has been successfully configured                     ***

***                                                                ***

***   If you encounter a problem while building, please open an    ***

***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***

***   and include the output from the following command:           ***

***                                                                ***

***       perl configdata.pm --dump                                ***

***                                                                ***

***   (If you are new to OpenSSL, you might want to consult the    ***

***   'Troubleshooting' section in the INSTALL file first)         ***

***                                                                ***

**********************************************************************

 

c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g>nmake

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
"-omakefile" "include\crypto\bn_conf.h.in" > include\crypto\bn_conf.h

        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
"-omakefile" "include\crypto\dso_conf.h.in" > include\crypto\dso_conf.h

        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
"-omakefile" "include\openssl\opensslconf.h.in" >
include\openssl\opensslconf.h

        "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" /
depend && "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" /
_all

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2
/I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Foapps\app_rand.obj
"apps\app_rand.c"

app_rand.c

 

*** lots of similar output before fatal error

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/bf1dd430/attachment-0001.html>

From bcloutier at integpg.com  Thu Jun 25 17:04:10 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Thu, 25 Jun 2020 13:04:10 -0400
Subject: server key exchange signature behavior
In-Reply-To: <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>

Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
the wrong key. Just need confirmation that there isn't a default key
configuration setting for OpenSSL that might be taking precedence for
who knows why.

I can connect successfully with the browser so I cannot rule out that my
TLS implementation is faulty. However, it validates with every other
site and it validates with the default install of this bitnami stack.
Once we reconfigure for the new key and certificate, this signature in
the server_key_exchange message fails. Nothing else seems to complain.
My code does, well, because I know that I actually do verify that
signature against the supplied certificate.

So to everyone else it appears that we have configured the new
certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
fails to validate this particular digital signature that would be the
case. If in my TLS implementation I skip this check (actually now I just
post a warning) everything negotiates and proceeds just fine.

Obviously, THAT signature is there for a reason. I should expect if to
validate. Just don't know what key it is using?

I am not sure how to get to the Apache people or, might be, the Bitnami
folks?

Bruce

On 6/25/20 12:07 PM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>> Bruce Cloutier
>> Sent: Thursday, June 25, 2020 10:11
>>
>> Has anyone thought about this question?
> From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
>
>> The site is https://jnior.com if
>> anyone wants to hit it. For me the digital signature in the
>> server_key_exchange does not verify.
> I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/f82eaf68/attachment.sig>

From bcloutier at integpg.com  Thu Jun 25 17:09:48 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Thu, 25 Jun 2020 13:09:48 -0400
Subject: server key exchange signature behavior
In-Reply-To: <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
Message-ID: <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>

Sorry,

By "If OpenSSL fails to validate this particular digital signature that
would be the case." I meant to question whether or not OpenSSL is in
fact doing the validation? In the case that the signature is being
ignored then clients wouldn't complain. They wouldn't notice.

Bruce

On 6/25/20 1:04 PM, Bruce Cloutier wrote:
> Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
> the wrong key. Just need confirmation that there isn't a default key
> configuration setting for OpenSSL that might be taking precedence for
> who knows why.
>
> I can connect successfully with the browser so I cannot rule out that my
> TLS implementation is faulty. However, it validates with every other
> site and it validates with the default install of this bitnami stack.
> Once we reconfigure for the new key and certificate, this signature in
> the server_key_exchange message fails. Nothing else seems to complain.
> My code does, well, because I know that I actually do verify that
> signature against the supplied certificate.
>
> So to everyone else it appears that we have configured the new
> certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
> fails to validate this particular digital signature that would be the
> case. If in my TLS implementation I skip this check (actually now I just
> post a warning) everything negotiates and proceeds just fine.
>
> Obviously, THAT signature is there for a reason. I should expect if to
> validate. Just don't know what key it is using?
>
> I am not sure how to get to the Apache people or, might be, the Bitnami
> folks?
>
> Bruce
>
> On 6/25/20 12:07 PM, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>>> Bruce Cloutier
>>> Sent: Thursday, June 25, 2020 10:11
>>>
>>> Has anyone thought about this question?
>> From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
>>
>>> The site is https://jnior.com if
>>> anyone wants to hit it. For me the digital signature in the
>>> server_key_exchange does not verify.
>> I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/ba26630b/attachment.sig>

From jb-openssl at wisemo.com  Thu Jun 25 17:29:35 2020
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 25 Jun 2020 19:29:35 +0200
Subject: server key exchange signature behavior
In-Reply-To: <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
 <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
Message-ID: <8cc220a2-8b29-6ff5-e2cd-770a15d36f6e@wisemo.com>

You may also check out the results of the popular ssllabs.com test here:

https://www.ssllabs.com/ssltest/analyze.html?d=jnior.com&hideResults=on

Note however that in recent years they have become quite aggressive in
labeling things as "weak" when they are simply "slightly less than the
best that the latestbig-brand browsers support" with no consideration
for servers that try to provide compatibility for older clients in
addition to the latest hype.

As for the signature on the key exchange in SSL3/TLS1.0/TLS1.1/TLS 1.2
and the final signature in TLS1.3, those are the one signature that
causes the certificates to do anything meaningful, so I would expect all
but the most crappy clients to check it and make a very serious error
message "SOMEONE IS HACKING YOUR CONNECTION, PULL THE PLUG NOW!" or
something equally serious.

On 2020-06-25 19:09, Bruce Cloutier wrote:
> Sorry,
>
> By "If OpenSSL fails to validate this particular digital signature that
> would be the case." I meant to question whether or not OpenSSL is in
> fact doing the validation? In the case that the signature is being
> ignored then clients wouldn't complain. They wouldn't notice.
>
> Bruce
>
> On 6/25/20 1:04 PM, Bruce Cloutier wrote:
>> Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
>> the wrong key. Just need confirmation that there isn't a default key
>> configuration setting for OpenSSL that might be taking precedence for
>> who knows why.
>>
>> I can connect successfully with the browser so I cannot rule out that my
>> TLS implementation is faulty. However, it validates with every other
>> site and it validates with the default install of this bitnami stack.
>> Once we reconfigure for the new key and certificate, this signature in
>> the server_key_exchange message fails. Nothing else seems to complain.
>> My code does, well, because I know that I actually do verify that
>> signature against the supplied certificate.
>>
>> So to everyone else it appears that we have configured the new
>> certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
>> fails to validate this particular digital signature that would be the
>> case. If in my TLS implementation I skip this check (actually now I just
>> post a warning) everything negotiates and proceeds just fine.
>>
>> Obviously, THAT signature is there for a reason. I should expect if to
>> validate. Just don't know what key it is using?
>>
>> I am not sure how to get to the Apache people or, might be, the Bitnami
>> folks?
>>
>> Bruce
>>
>> On 6/25/20 12:07 PM, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>>>> Bruce Cloutier
>>>> Sent: Thursday, June 25, 2020 10:11
>>>>
>>>> Has anyone thought about this question?
>>>  From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
>>>
>>>> The site is https://jnior.com if
>>>> anyone wants to hit it. For me the digital signature in the
>>>> server_key_exchange does not verify.
>>> I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
>>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From Michael.Wojcik at microfocus.com  Thu Jun 25 17:32:22 2020
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 25 Jun 2020 17:32:22 +0000
Subject: server key exchange signature behavior
In-Reply-To: <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
 <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
Message-ID: <DM6PR18MB2700DA8C35F60B77869B927BF9920@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Bruce Cloutier
> Sent: Thursday, June 25, 2020 12:10
>
> By "If OpenSSL fails to validate this particular digital signature that
> would be the case." I meant to question whether or not OpenSSL is in
> fact doing the validation? In the case that the signature is being
> ignored then clients wouldn't complain. They wouldn't notice.

s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client.


[1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From Michael.Wojcik at microfocus.com  Thu Jun 25 17:32:23 2020
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 25 Jun 2020 17:32:23 +0000
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <022a01d64b11$3d237730$b76a6590$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
Message-ID: <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mhkelley2017 at gmail.com
> Sent: Thursday, June 25, 2020 11:54

> Error:  'ml64' is not recognized as an internal or external command,
> operable program or batch file.

It's part of Visual C. The VC-WIN64A-masm configuration (Configurations/50-masm.conf) specifies it as the assembler.

> Building with Visual Studio  2019 Community

Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or maybe it's part of some optional component?

In VS2017 Professional, which is what I have configured at the moment on this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks to VS's gratuitously complicated directory layout.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From bcloutier at integpg.com  Thu Jun 25 18:02:58 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Thu, 25 Jun 2020 14:02:58 -0400
Subject: server key exchange signature behavior
In-Reply-To: <DM6PR18MB2700DA8C35F60B77869B927BF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
 <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
 <DM6PR18MB2700DA8C35F60B77869B927BF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <fbb6e944-4fdd-f3dc-02ec-348beb059cae@integpg.com>

I agree that I am not being explicit regarding my terminology. I don't
mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
need to reach out.

Specifically, the Signature covering the EC Diffe-Hellman Server Params
in the server_key_exchange message that I eventually receive in making
an outgoing client connection from my TLS implementation, does not
decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
That is happening with this one server installation using Apache in a
Bitnami stack (Windows machine). My TLS code is running as part of the
operating system on our separate single board computer controller (JNIOR).

I use the public key extracted from the supplied certificate to decrypt
and then compare the calculated hash. This procedure has been successful
(and signatures verify/validate/match) in every other connection attempt
to other servers (including google.com). It also works with this Apache
server before we move away from the default key and certificate files.
Basically, our server is using some other key for this. Maybe still the
default. After we point configuration to a new certificate and key.

Yeah, I had at first thought that there was an intrusion. But in testing
with a clean sandboxed server we see the same results. Yes, it is most
likely an Apache configuration issue but, we've dug through all of that
and nothing jumps out.

So either we haven't configured every possible corner of this Apache
server correctly, or there is some odd extension to TLS that I've
missed. But as you all know, debugging in this area is difficult.

jnior.com is obviously public and we need to know if we have it
improperly configured. But, I need to know why in this one instance my
TLS implementation fails. In either case, it is an symptom that
shouldn't be ignored as you would agree.

The good news is that if there were an OpenSSL bug somewhat associated
with this, you all would have already mentioned it (I assume).

Bruce

On 6/25/20 1:32 PM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>> Bruce Cloutier
>> Sent: Thursday, June 25, 2020 12:10
>>
>> By "If OpenSSL fails to validate this particular digital signature that
>> would be the case." I meant to question whether or not OpenSSL is in
>> fact doing the validation? In the case that the signature is being
>> ignored then clients wouldn't complain. They wouldn't notice.
> s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client.
>
>
> [1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/a12ce784/attachment.sig>

From matt at openssl.org  Thu Jun 25 18:14:52 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 25 Jun 2020 19:14:52 +0100
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>



On 25/06/2020 18:32, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mhkelley2017 at gmail.com
>> Sent: Thursday, June 25, 2020 11:54
> 
>> Error:  'ml64' is not recognized as an internal or external command,
>> operable program or batch file.
> 
> It's part of Visual C. The VC-WIN64A-masm configuration (Configurations/50-masm.conf) specifies it as the assembler.

Note that using masm to compile OpenSSL is no longer supported by us
(although it might still work).

Preferred is to use the VC-WIN64A target and the nasm compiler.

If you use the Developer Studio command prompt (64-bit) it should have
all the environment variables set up already to find the various VS tools.

Matt


> 
>> Building with Visual Studio  2019 Community
> 
> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or maybe it's part of some optional component?
> 
> In VS2017 Professional, which is what I have configured at the moment on this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks to VS's gratuitously complicated directory layout.
> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> 

From tom.browder at gmail.com  Thu Jun 25 18:51:26 2020
From: tom.browder at gmail.com (Tom Browder)
Date: Thu, 25 Jun 2020 13:51:26 -0500
Subject: Private CA client cert file for iPad for a website
In-Reply-To: <8C1DAB17-86DB-421A-9016-654F17ACBEBA@webweaving.org>
References: <CAFMGiz9M0XSCfUXC_8b2s7Av7LYv348VzOsYQ=V7vrHFBnO5QA@mail.gmail.com>
 <8C1DAB17-86DB-421A-9016-654F17ACBEBA@webweaving.org>
Message-ID: <CAFMGiz8t_9ctMpi6_CAOd-es_vhVtotyN57qG-izQair1mF91w@mail.gmail.com>

On Thu, Jun 25, 2020 at 10:18 Dirk-Willem van Gulik <dirkx at webweaving.org>
wrote:

> On 25 Jun 2020, at 17:14, Tom Browder <tom.browder at gmail.com> wrote

...

> > Can anyone tell me how to generate an acceptable client cert for an iPad?

...

> Have a play with https://interop.redwax.eu/rs/scep/


Thanks, Dw, that looks like exactly what I'm looking for for Apple devices!

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200625/001da3ac/attachment.html>

From mhkelley2017 at gmail.com  Thu Jun 25 19:20:07 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Thu, 25 Jun 2020 13:20:07 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
Message-ID: <03d301d64b25$a3348690$e99d93b0$@gmail.com>

Thanks! That helped, but I have two follow-ups.

1) To whom would I suggest minor changes to the available installation
instructions to help avoid future such misunderstandings?
2) A subsequent fatal error (should this also be submitted as a new
thread?):

	Could Not Find
c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.

*** build output ***
cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "."
/I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes "ms\uplink.c" 2>&1 >
ms\uplink.d
        "C:\Perl64\bin\perl.exe" "util\mkdef.pl" crypto 32 > libcrypto.def
        IF EXIST .manifest DEL /F /Q .manifest
        IF EXIST libcrypto-1_1-x64.dll DEL /F /Q libcrypto-1_1-x64.dll
        link /nologo /debug /dll  /nologo /debug  /implib:libcrypto.lib
/out:libcrypto-1_1-x64.dll /def:libcrypto.def
@C:\Users\Owner\AppData\Local\Temp\nm26DC.tmp || (DEL /Q libcrypto-1_1-x64.*
libcrypto.lib && EXIT 1)
crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
'x64' conflicts with target machine type 'x86'
Could Not Find
c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
: return code '0x2'
Stop.

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
Caswell
Sent: Thursday, June 25, 2020 12:15 PM
To: openssl-users at openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 25/06/2020 18:32, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
Of mhkelley2017 at gmail.com
>> Sent: Thursday, June 25, 2020 11:54
> 
>> Error:  'ml64' is not recognized as an internal or external command,
>> operable program or batch file.
> 
> It's part of Visual C. The VC-WIN64A-masm configuration
(Configurations/50-masm.conf) specifies it as the assembler.

Note that using masm to compile OpenSSL is no longer supported by us
(although it might still work).

Preferred is to use the VC-WIN64A target and the nasm compiler.

If you use the Developer Studio command prompt (64-bit) it should have
all the environment variables set up already to find the various VS tools.

Matt


> 
>> Building with Visual Studio  2019 Community
> 
> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
maybe it's part of some optional component?
> 
> In VS2017 Professional, which is what I have configured at the moment on
this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
to VS's gratuitously complicated directory layout.
> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> 


From matt at openssl.org  Thu Jun 25 20:03:25 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 25 Jun 2020 21:03:25 +0100
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <03d301d64b25$a3348690$e99d93b0$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
Message-ID: <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>



On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
> Thanks! That helped, but I have two follow-ups.
> 
> 1) To whom would I suggest minor changes to the available installation
> instructions to help avoid future such misunderstandings?

You can raise on issue on Github. Or even better raise a PR with your
suggested changes. However, as it so happens the Windows instructions
have very recently been significantly updated - so some of your
suggestions may already have been included:

https://github.com/openssl/openssl/pull/12098

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

This usually occurs when attempting to build 64-bit OpenSSL using the
32-bit VisualStudio tools.

Matt



> Could Not Find
> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
> NMAKE : fatal error U1077: 'link' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
> : return code '0x2'
> Stop.
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
> Caswell
> Sent: Thursday, June 25, 2020 12:15 PM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 25/06/2020 18:32, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of mhkelley2017 at gmail.com
>>> Sent: Thursday, June 25, 2020 11:54
>>
>>> Error:  'ml64' is not recognized as an internal or external command,
>>> operable program or batch file.
>>
>> It's part of Visual C. The VC-WIN64A-masm configuration
> (Configurations/50-masm.conf) specifies it as the assembler.
> 
> Note that using masm to compile OpenSSL is no longer supported by us
> (although it might still work).
> 
> Preferred is to use the VC-WIN64A target and the nasm compiler.
> 
> If you use the Developer Studio command prompt (64-bit) it should have
> all the environment variables set up already to find the various VS tools.
> 
> Matt
> 
> 
>>
>>> Building with Visual Studio  2019 Community
>>
>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
> maybe it's part of some optional component?
>>
>> In VS2017 Professional, which is what I have configured at the moment on
> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
> to VS's gratuitously complicated directory layout.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
> 

From Michael.Wojcik at microfocus.com  Thu Jun 25 20:03:53 2020
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 25 Jun 2020 20:03:53 +0000
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <03d301d64b25$a3348690$e99d93b0$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
Message-ID: <DM6PR18MB2700E4674C76C693DECFFBC2F9920@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> mhkelley2017 at gmail.com
> Sent: Thursday, June 25, 2020 14:20

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

For some reason - I can't tell based on what you sent - your build has told the linker to output a 32-bit DLL instead of a 64-bit one. This object is 64-bit, and you appear to be trying to build the 64-bit DLL, but the linker thinks it's linking for 32-bit.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From mhkelley2017 at gmail.com  Thu Jun 25 23:47:16 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Thu, 25 Jun 2020 17:47:16 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
Message-ID: <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>

Thank you.  I suspected as much.

Can someone point me to sources of information about how to resolve this issue?  I simply don't believe I'm the only one who wants to build OpenSSL for use in a Windows 10 environment - someone must have been successful and be able to point me to additional information.

A few points that may be useful and then two specific questions.

1. I program exclusively for a Windows environment.  Most of what I develop should be portable, but it as almost exclusively for my own use, which is presently almost exclusively Windows.  I *may* at some future point go back to Linux, but not yet.

2. I have never used (or seen need to use) Visual Studio.  I downloaded a copy specifically to get this package installed.  I attempted to install for 64-bit use.   But it is not entirely clear to me to know which pars are actually being used.  Usually, I would have just used Mingw-w64 along with Windows ports of the standard complement of UNIX tools.  While I do have access to Cygwin, my preference is to either stick with Windows or make t full change back to UNIX.

3. I have built and installed a significant number of software packages, so am not really a newbie, but there are clear gaps in my knowledge and experience.

4. Before installing Visual Studio, I messed around quite a bit trying to figure out how I might modify the build process to work with my usual set of tools - mostly UNIX-tools ported to Windows environment.  My preference would be to find pointers to information of how to accomplish that.

THE SPECIFIC QUESTIONS:

1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?

2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?

I'd really appreciate any useful information or pointers to such.

Thanks. 


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: Thursday, June 25, 2020 2:03 PM
To: openssl-users at openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
> Thanks! That helped, but I have two follow-ups.
> 
> 1) To whom would I suggest minor changes to the available installation
> instructions to help avoid future such misunderstandings?

You can raise on issue on Github. Or even better raise a PR with your
suggested changes. However, as it so happens the Windows instructions
have very recently been significantly updated - so some of your
suggestions may already have been included:

https://github.com/openssl/openssl/pull/12098

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

This usually occurs when attempting to build 64-bit OpenSSL using the
32-bit VisualStudio tools.

Matt



> Could Not Find
> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
> NMAKE : fatal error U1077: 'link' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
> : return code '0x2'
> Stop.
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
> Caswell
> Sent: Thursday, June 25, 2020 12:15 PM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 25/06/2020 18:32, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of mhkelley2017 at gmail.com
>>> Sent: Thursday, June 25, 2020 11:54
>>
>>> Error:  'ml64' is not recognized as an internal or external command,
>>> operable program or batch file.
>>
>> It's part of Visual C. The VC-WIN64A-masm configuration
> (Configurations/50-masm.conf) specifies it as the assembler.
> 
> Note that using masm to compile OpenSSL is no longer supported by us
> (although it might still work).
> 
> Preferred is to use the VC-WIN64A target and the nasm compiler.
> 
> If you use the Developer Studio command prompt (64-bit) it should have
> all the environment variables set up already to find the various VS tools.
> 
> Matt
> 
> 
>>
>>> Building with Visual Studio  2019 Community
>>
>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
> maybe it's part of some optional component?
>>
>> In VS2017 Professional, which is what I have configured at the moment on
> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
> to VS's gratuitously complicated directory layout.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
> 


From janjust at nikhef.nl  Fri Jun 26 07:52:34 2020
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 26 Jun 2020 09:52:34 +0200
Subject: server key exchange signature behavior
In-Reply-To: <fbb6e944-4fdd-f3dc-02ec-348beb059cae@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
 <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
 <DM6PR18MB2700DA8C35F60B77869B927BF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <fbb6e944-4fdd-f3dc-02ec-348beb059cae@integpg.com>
Message-ID: <1a093433-4d47-ab99-5d75-bd240aec9c3f@nikhef.nl>

On 25/06/20 20:02, Bruce Cloutier wrote:
> I agree that I am not being explicit regarding my terminology. I don't
> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
> need to reach out.
>
> Specifically, the Signature covering the EC Diffe-Hellman Server Params
> in the server_key_exchange message that I eventually receive in making
> an outgoing client connection from my TLS implementation, does not
> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
> That is happening with this one server installation using Apache in a
> Bitnami stack (Windows machine). My TLS code is running as part of the
> operating system on our separate single board computer controller (JNIOR).
>
> I use the public key extracted from the supplied certificate to decrypt
> and then compare the calculated hash. This procedure has been successful
> (and signatures verify/validate/match) in every other connection attempt
> to other servers (including google.com). It also works with this Apache
> server before we move away from the default key and certificate files.
> Basically, our server is using some other key for this. Maybe still the
> default. After we point configuration to a new certificate and key.
>
> Yeah, I had at first thought that there was an intrusion. But in testing
> with a clean sandboxed server we see the same results. Yes, it is most
> likely an Apache configuration issue but, we've dug through all of that
> and nothing jumps out.
>
> So either we haven't configured every possible corner of this Apache
> server correctly, or there is some odd extension to TLS that I've
> missed. But as you all know, debugging in this area is difficult.
>
> jnior.com is obviously public and we need to know if we have it
> improperly configured. But, I need to know why in this one instance my
> TLS implementation fails. In either case, it is an symptom that
> shouldn't be ignored as you would agree.
>
> The good news is that if there were an OpenSSL bug somewhat associated
> with this, you all would have already mentioned it (I assume).
>

I'd suggest to run something like wireshark and capture the TLS 
handshake - if I do that against jnior.com I see that the jnior.com 
certificate has a X509 cert extension unknown to my rather old Wireshark 
version, but that should not matter much. Wireshark will give you 
detailed info about the EC Diffie-Hellman Server Params that were sent 
over the wire, including the signature. Wireshark does not indicate any 
problems there, although I am not sure if it *would* , if there was a 
problem.

However, it will give you an easy method to see what wireshark thinks 
the signature is compared to what your code thinks the signature is.

As a side-remark: I did notice your server cert is using 3072 bit RSA 
whereas the CAs are based on 2048bit RSA - nothing wrong with that, but 
do make sure your code can handle that (under normal circumstances it 
would not be an issue).

HTH,

JJK

> On 6/25/20 1:32 PM, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>>> Bruce Cloutier
>>> Sent: Thursday, June 25, 2020 12:10
>>>
>>> By "If OpenSSL fails to validate this particular digital signature that
>>> would be the case." I meant to question whether or not OpenSSL is in
>>> fact doing the validation? In the case that the signature is being
>>> ignored then clients wouldn't complain. They wouldn't notice.
>> s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client.
>>
>>
>> [1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>


From matt at openssl.org  Fri Jun 26 09:03:52 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2020 10:03:52 +0100
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
Message-ID: <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>



On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?

My windows environment died on my recently, so I can't check the actual
output. IIRC just typing "cl" at the command line should give you
details about the compiler being used and whether it is for 32 or 64 bits.

Visual Studio has a number of "developer command prompts" available with
it. If you start one of those it should have all the right environment
variables set up for you. There should be different command prompts for
32 bit vs 64 bit.

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

Alternatively there is the vcvarsall.bat script which comes with VS that
enables you to setup all the environment variables - you can specify as
an argument to script whether you are targeting 32 bit or 64 bit.

https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

As well as the VS tools environment variables you will need to make sure
both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
%PATH%.


> 
> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?

You can do this using the MinGW compilers and the MSys2 shell. Note the
MinGW compilers target *native* windows. So although you use Msys2 to
build it, the resulting binaries are fully native.


There are details in the newly rewritten instructions for Windows:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN

Matt


> 
> I'd really appreciate any useful information or pointers to such.
> 
> Thanks. 
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: Thursday, June 25, 2020 2:03 PM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>> Thanks! That helped, but I have two follow-ups.
>>
>> 1) To whom would I suggest minor changes to the available installation
>> instructions to help avoid future such misunderstandings?
> 
> You can raise on issue on Github. Or even better raise a PR with your
> suggested changes. However, as it so happens the Windows instructions
> have very recently been significantly updated - so some of your
> suggestions may already have been included:
> 
> https://github.com/openssl/openssl/pull/12098
> 
>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>> 'x64' conflicts with target machine type 'x86'
> 
> This usually occurs when attempting to build 64-bit OpenSSL using the
> 32-bit VisualStudio tools.
> 
> Matt
> 
> 
> 
>> Could Not Find
>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>> : return code '0x2'
>> Stop.
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>> Caswell
>> Sent: Thursday, June 25, 2020 12:15 PM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of mhkelley2017 at gmail.com
>>>> Sent: Thursday, June 25, 2020 11:54
>>>
>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>> operable program or batch file.
>>>
>>> It's part of Visual C. The VC-WIN64A-masm configuration
>> (Configurations/50-masm.conf) specifies it as the assembler.
>>
>> Note that using masm to compile OpenSSL is no longer supported by us
>> (although it might still work).
>>
>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>
>> If you use the Developer Studio command prompt (64-bit) it should have
>> all the environment variables set up already to find the various VS tools.
>>
>> Matt
>>
>>
>>>
>>>> Building with Visual Studio  2019 Community
>>>
>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>> maybe it's part of some optional component?
>>>
>>> In VS2017 Professional, which is what I have configured at the moment on
>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>> to VS's gratuitously complicated directory layout.
>>>
>>> --
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>>
> 

From openssl at pmail.gen.nz  Fri Jun 26 09:45:56 2020
From: openssl at pmail.gen.nz (David Harris)
Date: Fri, 26 Jun 2020 21:45:56 +1200
Subject: OpenSSL 1.1.1g test failures
Message-ID: <5EF5C3D4.17497.C50E3BE2@openssl.pmail.gen.nz>

Environment: Windows 7 (I know, I know - I just hate Windows 10).
Compiler: Visual Studio, have tried both VS2008 Pro and VS2019 Pro
OpenSSL Build: 1.1.1g, retrieved from OpenSSL.org last night

I've been attempting to build OpenSSL 1.1.x since it came out, but each time I do so, 
I find that, while it compiles and links cleanly, it fails about 50% of its self tests when 
I perform "nmake test". It has been this way for several releases. By "fail" I mean 
that there's a stream of "dubious..." outputs that look like this excerpt:

-------------------------- Cut here ----------------------------
...
test\recipes\03-test_internal_siphash.t ......... ok
test\recipes\03-test_internal_sm2.t ............. ok
test\recipes\03-test_internal_sm4.t ............. ok
test\recipes\03-test_internal_ssl_cert_table.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
test\recipes\03-test_internal_x509.t ............ ok
test\recipes\03-test_ui.t ....................... ok
test\recipes\04-test_asn1_decode.t .............. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
test\recipes\04-test_asn1_encode.t .............. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
...
-------------------------- Cut here ----------------------------

Each time I went through the process, I saw the long string of self-test failures and 
decided I'd put off migrating to 1.1.1 until it was sorted out, but it's been the same for 
at least four releases now. I finally decided I needed to track down what was going 
on, so I extrapolated how to run the failing tests manually with more verbose output 
from the OpenSSL wiki pages (which are just a little out of date).

It appears that for at least the first twenty or thirty of these failures, the reason is 
because the test application has been compiled without including the required 
Applink code - a verbose output typically looks like this:

-------------------------- Cut here ----------------------------
O:\ >perl test\recipes\05-test_idea.t
1..1
OPENSSL_Uplink(5C790330,08): no OPENSSL_Applink
..\ideatest.exe => 1
not ok 1 - running ideatest
#   Failed test 'running ideatest'
#   at util/perl/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed 1 test of 1.
-------------------------- Cut here ----------------------------

Is this just the way it is? I would have thought that 50% self-test failure would be 
ringing alarm bells everywhere if it were common, so I can only conclude that there's 
something odd about my environment, or that I'm doing something wrong, but this is 
about as vanilla a build process as I can possibly make it. I follow the steps for 
Win32 in INSTALL, and as I said at the start of this message, the nmake process 
goes cleanly, not a single warning or error. The ONLY non-standard thing I do is 
change the /MD switch (link to the DLL versions of the runtime libraries) to /MT 
(static link the runtimes) because I don't want to have external dependencies in my 
production environments (I lived in "DLL Hell" for so long that I'm now quite paranoid 
about that). This change has never caused problems in the past, and doesn't seem 
to be relevant to the problems I'm seeing.

I've been building OpenSSL myself for a number of years, most recently with the 
end-of-life v1.0.2 builds, which always go without a hitch. As I remarked, I've been 
putting off moving to v1.1.1 because I'm so uneasy about these self-test failures, but 
I can't continue doing that any longer as TLS3 starts coming on stream.

Anyone have any insights into what I'm doing wrong, or what I can do about this? I'm 
very reluctant to use the software in production if it can't pass its own self-test 
regime, even if it appears to work normally otherwise.

Comments most welcome.

Cheers!

-- David --


From bcloutier at integpg.com  Fri Jun 26 10:23:04 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Fri, 26 Jun 2020 06:23:04 -0400
Subject: server key exchange signature behavior
In-Reply-To: <1a093433-4d47-ab99-5d75-bd240aec9c3f@nikhef.nl>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
 <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
 <DM6PR18MB2700DA8C35F60B77869B927BF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <fbb6e944-4fdd-f3dc-02ec-348beb059cae@integpg.com>
 <1a093433-4d47-ab99-5d75-bd240aec9c3f@nikhef.nl>
Message-ID: <fb799b0e-8fb4-ae6b-3a4d-f9e0b621c9ed@integpg.com>

Jan,

Use Wireshark all of the time. In fact I've used it since before it was
Wireshark. But now... I can't remember what it was called before. Great
tool.

You, though, may have hit on something in pointing out the 3072 bit key.
I will check on that. It was a design decision in developing this
controller that no 3rd party code be used. Consequently I have authored
every byte of the OS including the stack. So the multi-precision math is
all mine and... it does have a limit. I may have set it with the 2,048
bit keys in mind. This would absolutely fit with the symptoms. Let me
verify.

Thank you!

Bruce

On 6/26/20 3:52 AM, Jan Just Keijser wrote:
> On 25/06/20 20:02, Bruce Cloutier wrote:
>> I agree that I am not being explicit regarding my terminology. I don't
>> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
>> need to reach out.
>>
>> Specifically, the Signature covering the EC Diffe-Hellman Server Params
>> in the server_key_exchange message that I eventually receive in making
>> an outgoing client connection from my TLS implementation, does not
>> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
>> That is happening with this one server installation using Apache in a
>> Bitnami stack (Windows machine). My TLS code is running as part of the
>> operating system on our separate single board computer controller
>> (JNIOR).
>>
>> I use the public key extracted from the supplied certificate to decrypt
>> and then compare the calculated hash. This procedure has been successful
>> (and signatures verify/validate/match) in every other connection attempt
>> to other servers (including google.com). It also works with this Apache
>> server before we move away from the default key and certificate files.
>> Basically, our server is using some other key for this. Maybe still the
>> default. After we point configuration to a new certificate and key.
>>
>> Yeah, I had at first thought that there was an intrusion. But in testing
>> with a clean sandboxed server we see the same results. Yes, it is most
>> likely an Apache configuration issue but, we've dug through all of that
>> and nothing jumps out.
>>
>> So either we haven't configured every possible corner of this Apache
>> server correctly, or there is some odd extension to TLS that I've
>> missed. But as you all know, debugging in this area is difficult.
>>
>> jnior.com is obviously public and we need to know if we have it
>> improperly configured. But, I need to know why in this one instance my
>> TLS implementation fails. In either case, it is an symptom that
>> shouldn't be ignored as you would agree.
>>
>> The good news is that if there were an OpenSSL bug somewhat associated
>> with this, you all would have already mentioned it (I assume).
>>
>
> I'd suggest to run something like wireshark and capture the TLS
> handshake - if I do that against jnior.com I see that the jnior.com
> certificate has a X509 cert extension unknown to my rather old
> Wireshark version, but that should not matter much. Wireshark will
> give you detailed info about the EC Diffie-Hellman Server Params that
> were sent over the wire, including the signature. Wireshark does not
> indicate any problems there, although I am not sure if it *would* , if
> there was a problem.
>
> However, it will give you an easy method to see what wireshark thinks
> the signature is compared to what your code thinks the signature is.
>
> As a side-remark: I did notice your server cert is using 3072 bit RSA
> whereas the CAs are based on 2048bit RSA - nothing wrong with that,
> but do make sure your code can handle that (under normal circumstances
> it would not be an issue).
>
> HTH,
>
> JJK
>
>> On 6/25/20 1:32 PM, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
>>>> Behalf Of
>>>> Bruce Cloutier
>>>> Sent: Thursday, June 25, 2020 12:10
>>>>
>>>> By "If OpenSSL fails to validate this particular digital signature
>>>> that
>>>> would be the case." I meant to question whether or not OpenSSL is in
>>>> fact doing the validation? In the case that the signature is being
>>>> ignored then clients wouldn't complain. They wouldn't notice.
>>> s_client should be verifying the signature.[1] That is, it should be
>>> verifying every signature that's part of the actual TLS protocol. I
>>> admit it's not entirely clear to me which signature isn't being
>>> verified successfully by your client.
>>>
>>>
>>> [1] I'm not sure "validate" is the proper term here, technically
>>> speaking. In my experience, the literature usually uses "verify" for
>>> confirming a signature. "Validate" is generally used for more
>>> complex protocols, such as certificate validation, which involves a
>>> large number of steps with various types of checks.
>>>
>>> -- 
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/71d68a17/attachment.sig>

From matt at openssl.org  Fri Jun 26 10:55:02 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2020 11:55:02 +0100
Subject: OpenSSL 1.1.1g test failures
In-Reply-To: <5EF5C3D4.17497.C50E3BE2@openssl.pmail.gen.nz>
References: <5EF5C3D4.17497.C50E3BE2@openssl.pmail.gen.nz>
Message-ID: <2373eeb9-b5f4-404c-c58d-d9d25597223d@openssl.org>



On 26/06/2020 10:45, David Harris wrote:

> Is this just the way it is? I would have thought that 50% self-test failure would be 
> ringing alarm bells everywhere if it were common, so I can only conclude that there's 
> something odd about my environment, or that I'm doing something wrong, but this is 
> about as vanilla a build process as I can possibly make it.

No - this is not normal output. We would expect the self tests to pass
on Windows (and they do), e.g.

https://ci.appveyor.com/project/openssl/openssl/builds/33676970


> I follow the steps for 
> Win32 in INSTALL, and as I said at the start of this message, the nmake process 
> goes cleanly, not a single warning or error. The ONLY non-standard thing I do is 
> change the /MD switch (link to the DLL versions of the runtime libraries) to /MT 
> (static link the runtimes) because I don't want to have external dependencies in my 
> production environments (I lived in "DLL Hell" for so long that I'm now quite paranoid 
> about that). This change has never caused problems in the past, and doesn't seem 
> to be relevant to the problems I'm seeing.
> 

How exactly do you make this change? By editing the Makefile? Have you
tried it without doing this? My guess is that this is exactly the cause
of the problem. AppLink is all about dealing with differences in MS
runtimes.

Matt

From bcloutier at integpg.com  Fri Jun 26 12:13:35 2020
From: bcloutier at integpg.com (Bruce Cloutier)
Date: Fri, 26 Jun 2020 08:13:35 -0400
Subject: server key exchange signature behavior
In-Reply-To: <fb799b0e-8fb4-ae6b-3a4d-f9e0b621c9ed@integpg.com>
References: <3ecb8c91-f32d-01e4-03c3-bfc64aa7767b@integpg.com>
 <9742b23e-cfd1-8344-ba85-09c7e97fd462@integpg.com>
 <DM6PR18MB270039AF7E5EE85C976CB0F4F9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <4c0d0084-5fd0-4f1b-5355-318fe32c29cc@integpg.com>
 <c18a5a77-3698-2f77-d278-b4e642944941@integpg.com>
 <DM6PR18MB2700DA8C35F60B77869B927BF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <fbb6e944-4fdd-f3dc-02ec-348beb059cae@integpg.com>
 <1a093433-4d47-ab99-5d75-bd240aec9c3f@nikhef.nl>
 <fb799b0e-8fb4-ae6b-3a4d-f9e0b621c9ed@integpg.com>
Message-ID: <945977f6-aad9-58ed-be71-3a3eae524011@integpg.com>

Thank you JJK and everyone!!

Jan, that was it! Never thought to check the key size. Just too close to
it I guess. I could handle the 2,048 bit keys but set a fixed maximum
register size of 4,096 bits. Well, it needs 6,144 bits to do the 3,072
bit math. My bad as they say. I do have a ToDo in the comments to
implement dynamic sizing. After all, my target is just a
micro-controller based device at 100 MHz. Security needs to be
functional and, well, not necessarily strong. Most neglect to move away
from default passwords. Ugh.

I'll probably roll jnior.com back to 2,048. I did not purposely set the
larger key size. Must have been someone's idea of a good default.

Oh... and it was Ethereal before Wireshark. I had to look it up.
Starting to get concerned about my memory. But, I do have valid 30-year
old backups of past systems and am certain I can I actually pull a
version off that if I really wanted.

I was just adding Elliptic Curve capabilities to my TLS as something to
do during this pandemic. Yeah, finally. It is an academic endeavor in
keeping with my DIY edict.

Thank you all. And, Jan you are a star!!

Bruce

On 6/26/20 6:23 AM, Bruce Cloutier wrote:
> Jan,
>
> Use Wireshark all of the time. In fact I've used it since before it was
> Wireshark. But now... I can't remember what it was called before. Great
> tool.
>
> You, though, may have hit on something in pointing out the 3072 bit key.
> I will check on that. It was a design decision in developing this
> controller that no 3rd party code be used. Consequently I have authored
> every byte of the OS including the stack. So the multi-precision math is
> all mine and... it does have a limit. I may have set it with the 2,048
> bit keys in mind. This would absolutely fit with the symptoms. Let me
> verify.
>
> Thank you!
>
> Bruce
>
> On 6/26/20 3:52 AM, Jan Just Keijser wrote:
>> On 25/06/20 20:02, Bruce Cloutier wrote:
>>> I agree that I am not being explicit regarding my terminology. I don't
>>> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
>>> need to reach out.
>>>
>>> Specifically, the Signature covering the EC Diffe-Hellman Server Params
>>> in the server_key_exchange message that I eventually receive in making
>>> an outgoing client connection from my TLS implementation, does not
>>> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
>>> That is happening with this one server installation using Apache in a
>>> Bitnami stack (Windows machine). My TLS code is running as part of the
>>> operating system on our separate single board computer controller
>>> (JNIOR).
>>>
>>> I use the public key extracted from the supplied certificate to decrypt
>>> and then compare the calculated hash. This procedure has been successful
>>> (and signatures verify/validate/match) in every other connection attempt
>>> to other servers (including google.com). It also works with this Apache
>>> server before we move away from the default key and certificate files.
>>> Basically, our server is using some other key for this. Maybe still the
>>> default. After we point configuration to a new certificate and key.
>>>
>>> Yeah, I had at first thought that there was an intrusion. But in testing
>>> with a clean sandboxed server we see the same results. Yes, it is most
>>> likely an Apache configuration issue but, we've dug through all of that
>>> and nothing jumps out.
>>>
>>> So either we haven't configured every possible corner of this Apache
>>> server correctly, or there is some odd extension to TLS that I've
>>> missed. But as you all know, debugging in this area is difficult.
>>>
>>> jnior.com is obviously public and we need to know if we have it
>>> improperly configured. But, I need to know why in this one instance my
>>> TLS implementation fails. In either case, it is an symptom that
>>> shouldn't be ignored as you would agree.
>>>
>>> The good news is that if there were an OpenSSL bug somewhat associated
>>> with this, you all would have already mentioned it (I assume).
>>>
>> I'd suggest to run something like wireshark and capture the TLS
>> handshake - if I do that against jnior.com I see that the jnior.com
>> certificate has a X509 cert extension unknown to my rather old
>> Wireshark version, but that should not matter much. Wireshark will
>> give you detailed info about the EC Diffie-Hellman Server Params that
>> were sent over the wire, including the signature. Wireshark does not
>> indicate any problems there, although I am not sure if it *would* , if
>> there was a problem.
>>
>> However, it will give you an easy method to see what wireshark thinks
>> the signature is compared to what your code thinks the signature is.
>>
>> As a side-remark: I did notice your server cert is using 3072 bit RSA
>> whereas the CAs are based on 2048bit RSA - nothing wrong with that,
>> but do make sure your code can handle that (under normal circumstances
>> it would not be an issue).
>>
>> HTH,
>>
>> JJK
>>
>>> On 6/25/20 1:32 PM, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
>>>>> Behalf Of
>>>>> Bruce Cloutier
>>>>> Sent: Thursday, June 25, 2020 12:10
>>>>>
>>>>> By "If OpenSSL fails to validate this particular digital signature
>>>>> that
>>>>> would be the case." I meant to question whether or not OpenSSL is in
>>>>> fact doing the validation? In the case that the signature is being
>>>>> ignored then clients wouldn't complain. They wouldn't notice.
>>>> s_client should be verifying the signature.[1] That is, it should be
>>>> verifying every signature that's part of the actual TLS protocol. I
>>>> admit it's not entirely clear to me which signature isn't being
>>>> verified successfully by your client.
>>>>
>>>>
>>>> [1] I'm not sure "validate" is the proper term here, technically
>>>> speaking. In my experience, the literature usually uses "verify" for
>>>> confirming a signature. "Validate" is generally used for more
>>>> complex protocols, such as certificate validation, which involves a
>>>> large number of steps with various types of checks.
>>>>
>>>> -- 
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>
>>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/31f0cbbf/attachment-0001.sig>

From mhkelley2017 at gmail.com  Fri Jun 26 13:27:06 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 07:27:06 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
Message-ID: <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>

Matt,

Thanks for your suggestion ...

>> 
>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>> 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.

That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..

Here is how far I got  I have been unable to even figure out where this error comes from ...

----------------------------------------------------------------------------------
$ where perl
C:\Perl64\bin\perl.exe
$ perl Configure mingw --prefix=$PREFIX
******************************************************************************
This perl implementation doesn't produce Unix like paths (with forward slash
directory separators).  Please use an implementation that matches your
building platform.

This Perl version: 5.24.3 for MSWin32-x64-multi-thread
******************************************************************************
Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
Using os-specific seed configuration
----------------------------------------------------------------------------------


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 3:04 AM
To: openssl-users at openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?

My windows environment died on my recently, so I can't check the actual
output. IIRC just typing "cl" at the command line should give you
details about the compiler being used and whether it is for 32 or 64 bits.

Visual Studio has a number of "developer command prompts" available with
it. If you start one of those it should have all the right environment
variables set up for you. There should be different command prompts for
32 bit vs 64 bit.

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

Alternatively there is the vcvarsall.bat script which comes with VS that
enables you to setup all the environment variables - you can specify as
an argument to script whether you are targeting 32 bit or 64 bit.

https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

As well as the VS tools environment variables you will need to make sure
both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
%PATH%.


> 
> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?

You can do this using the MinGW compilers and the MSys2 shell. Note the
MinGW compilers target *native* windows. So although you use Msys2 to
build it, the resulting binaries are fully native.


There are details in the newly rewritten instructions for Windows:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN

Matt


> 
> I'd really appreciate any useful information or pointers to such.
> 
> Thanks. 
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: Thursday, June 25, 2020 2:03 PM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>> Thanks! That helped, but I have two follow-ups.
>>
>> 1) To whom would I suggest minor changes to the available installation
>> instructions to help avoid future such misunderstandings?
> 
> You can raise on issue on Github. Or even better raise a PR with your
> suggested changes. However, as it so happens the Windows instructions
> have very recently been significantly updated - so some of your
> suggestions may already have been included:
> 
> https://github.com/openssl/openssl/pull/12098
> 
>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>> 'x64' conflicts with target machine type 'x86'
> 
> This usually occurs when attempting to build 64-bit OpenSSL using the
> 32-bit VisualStudio tools.
> 
> Matt
> 
> 
> 
>> Could Not Find
>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>> : return code '0x2'
>> Stop.
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>> Caswell
>> Sent: Thursday, June 25, 2020 12:15 PM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of mhkelley2017 at gmail.com
>>>> Sent: Thursday, June 25, 2020 11:54
>>>
>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>> operable program or batch file.
>>>
>>> It's part of Visual C. The VC-WIN64A-masm configuration
>> (Configurations/50-masm.conf) specifies it as the assembler.
>>
>> Note that using masm to compile OpenSSL is no longer supported by us
>> (although it might still work).
>>
>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>
>> If you use the Developer Studio command prompt (64-bit) it should have
>> all the environment variables set up already to find the various VS tools.
>>
>> Matt
>>
>>
>>>
>>>> Building with Visual Studio  2019 Community
>>>
>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>> maybe it's part of some optional component?
>>>
>>> In VS2017 Professional, which is what I have configured at the moment on
>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>> to VS's gratuitously complicated directory layout.
>>>
>>> --
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>>
> 


From matt at openssl.org  Fri Jun 26 13:30:37 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2020 14:30:37 +0100
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
Message-ID: <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>



On 26/06/2020 14:27, mhkelley2017 at gmail.com wrote:
> Matt,
> 
> Thanks for your suggestion ...
> 
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
> 
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
> 
> Here is how far I got  I have been unable to even figure out where this error comes from ...
> 
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
> 
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
> 
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
> 
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
> 
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
> 
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
> 
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
> 
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
> 
> 
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
> 
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
> 
> 
> There are details in the newly rewritten instructions for Windows:
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
> 
> Matt
> 
> 
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks. 
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>> Of mhkelley2017 at gmail.com
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
> 

From openssl at pmail.gen.nz  Fri Jun 26 14:01:09 2020
From: openssl at pmail.gen.nz (David Harris)
Date: Sat, 27 Jun 2020 02:01:09 +1200
Subject: OpenSSL 1.1.1g test failures
In-Reply-To: <2373eeb9-b5f4-404c-c58d-d9d25597223d@openssl.org>
References: <5EF5C3D4.17497.C50E3BE2@openssl.pmail.gen.nz>,
 <2373eeb9-b5f4-404c-c58d-d9d25597223d@openssl.org>
Message-ID: <5EF5FFA5.24568.C5F7E5FB@openssl.pmail.gen.nz>

On 26 Jun 2020 at 11:55, Matt Caswell wrote:

> No - this is not normal output. We would expect the self tests to pass
> on Windows

> >  The ONLY
> > non-standard thing I do is change the /MD switch (link to the DLL
> > versions of the runtime libraries) to /MT (static link the runtimes)
> > because I don't want to have external dependencies in my production
> > environments
> 
> How exactly do you make this change? By editing the Makefile? Have you
> tried it without doing this? My guess is that this is exactly the
> cause of the problem. AppLink is all about dealing with differences in
> MS runtimes.

Assumption, as they say, is the mother of all fu??ups...

In this case, the failed assumption was that a non-standard modification I had 
been making for many years would continue to work simply because it had in 
the past.

Matt is, of course, quite right. When I changed the "/MT" back to "/MD" in 
CNF_CFLAGS and rebuilt everything, it all worked like clockwork.

My thanks to you Matt - you've solved my problem.

Is there a standard (i.e, approved) way of using the static RTLs instead of the 
DLL ones? Or is my only option to modify the applink code so that it checks its 
environment in a different way? The problem with the dynamic RTLs is that my 
application is often used in environments where the user may not have sufficient 
rights to install the redistributables - whereas, if I use the static versions, the 
code is a little bigger, but there's no redistributable installation required and I 
never run into rights issues.

Again, thank you for the assistance, Matt - I appreciate it.

Cheers!

-- David --


From mhkelley2017 at gmail.com  Fri Jun 26 14:58:32 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 08:58:32 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
Message-ID: <00d801d64bca$42b3b980$c81b2c80$@gmail.com>

Matt,

I fear I my wear out my welcome before I manage to get a working OpenSSL ...

> Make sure msys2 has the perl package installed and remove
> this one from your path.

OK, I'll bite.

As near as I can tell, this suggestion means one of two things.

1) use one of the "completion"  functions named "perl" that apparently came with the original MSYS2 installation (both in folder msys64\usr\share\bash-completion\completions).  Since neither seemed to do anything useful here, I presume you mean

2) install a perl package from MSYS2 for use with MSYS2.  If this is what you meant, I still have two apparently relevant choices.

a) mingw-w64-perl
b) perl (seems specific to Cygwin and Linux)

The former gives me the same error as ActivePerl
The latter seems to be just ignored.

I'm clearly missing something, but must be too dense to figure out what.

Mike

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 7:31 AM
To: openssl-users at openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:27, mhkelley2017 at gmail.com wrote:
> Matt,
> 
> Thanks for your suggestion ...
> 
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
> 
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
> 
> Here is how far I got  I have been unable to even figure out where this error comes from ...
> 
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
> 
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
> 
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
> 
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
> 
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
> 
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
> 
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
> 
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
> 
> 
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
> 
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
> 
> 
> There are details in the newly rewritten instructions for Windows:
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
> 
> Matt
> 
> 
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks. 
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>> Of mhkelley2017 at gmail.com
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
> 


From sfhacker at hotmail.com  Fri Jun 26 14:59:15 2020
From: sfhacker at hotmail.com (Sergio NNX)
Date: Fri, 26 Jun 2020 14:59:15 +0000
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>,
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
Message-ID: <DM5PR1301MB19148AD4B01F2FD5D3B928A9CC930@DM5PR1301MB1914.namprd13.prod.outlook.com>

It is so easy to build OpenSSL using MinGW/MSYS!

Just type: ./Configure mingw64 ....... <whatever options you need/want>
                  make all

[cid:244b0963-a277-473a-95fe-9419d8ef84d0]

How much experience do you have building apps from source on Windows? VS didn't work, MinGW didn't work either!
We are more than happy to assist you.

Have fun.

________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Matt Caswell <matt at openssl.org>
Sent: Friday, 26 June 2020 11:30 PM
To: openssl-users at openssl.org <openssl-users at openssl.org>
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:27, mhkelley2017 at gmail.com wrote:
> Matt,
>
> Thanks for your suggestion ...
>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
>
> Here is how far I got  I have been unable to even figure out where this error comes from ...
>
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
>
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
>
>
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users at openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
>
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
>
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
>
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
>
>
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
>
>
> There are details in the newly rewritten instructions for Windows:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>
> Matt
>
>
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks.
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>> Of mhkelley2017 at gmail.com
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/976d77a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26123 bytes
Desc: image.png
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/976d77a5/attachment-0001.png>

From mhkelley2017 at gmail.com  Fri Jun 26 15:14:46 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 09:14:46 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <DM5PR1301MB19148AD4B01F2FD5D3B928A9CC930@DM5PR1301MB1914.namprd13.prod.outlook.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>,
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
 <DM5PR1301MB19148AD4B01F2FD5D3B928A9CC930@DM5PR1301MB1914.namprd13.prod.outlook.com>
Message-ID: <00e501d64bcc$872f8ba0$958ea2e0$@gmail.com>

Thanks.

 

But apparently you missed one of my earlier posts.

 

I have a fair bit of experience building apps from source.  My general
experience is that the instructions provided are nearly correct, but that
the user must do a little tweaking of the process - presumably because the
underlying process is quite complex and depends a *very many* case-specific
system configuration details.  Hence, I am quite comfortable debugging most
installation processes to get them to work.

 

Following your suggestion, I get (and reported) the following result:

 

----------------------------------------------------------------------------
------------

Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw64

Using os-specific seed configuration

 

****************************************************************************
**

This perl implementation doesn't produce Unix like paths (with forward slash

directory separators).  Please use an implementation that matches your

building platform.

 

This Perl version: 5.28.0 for MSWin32-x64-multi-thread

****************************************************************************
**

----------------------------------------------------------------------------
------------

 

So clearly, either 1) you have done something different from just enter the
configure command, or 2) I have something in my programming environment that
is different from yours.

 

I'm simply trying to figure out one of those differences.

 

Mike

 

From: Sergio NNX <sfhacker at hotmail.com> 
Sent: Friday, June 26, 2020 8:59 AM
To: openssl-users at openssl.org
Cc: mhkelley2017 at gmail.com
Subject: Re: Error building OpenSSL-1.1.1g

 

It is so easy to build OpenSSL using MinGW/MSYS!

 

Just type: ./Configure mingw64 ....... <whatever options you need/want>

                  make all

 



 

How much experience do you have building apps from source on Windows? VS
didn't work, MinGW didn't work either!

We are more than happy to assist you.

 

Have fun.

 

  _____  

From: openssl-users <openssl-users-bounces at openssl.org
<mailto:openssl-users-bounces at openssl.org> > on behalf of Matt Caswell
<matt at openssl.org <mailto:matt at openssl.org> >
Sent: Friday, 26 June 2020 11:30 PM
To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
<openssl-users at openssl.org <mailto:openssl-users at openssl.org> >
Subject: Re: Error building OpenSSL-1.1.1g 

 



On 26/06/2020 14:27, mhkelley2017 at gmail.com <mailto:mhkelley2017 at gmail.com>
wrote:
> Matt,
> 
> Thanks for your suggestion ...
> 
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
> 
> That was one of the first things I tried.  After exploring a few rabbit
holes, I gave up and downloaded Visual Studio..
> 
> Here is how far I got  I have been unable to even figure out where this
error comes from ...
> 
>
----------------------------------------------------------------------------
------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
>
****************************************************************************
**
> This perl implementation doesn't produce Unix like paths (with forward
slash
> directory separators).  Please use an implementation that matches your
> building platform.
> 
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>
****************************************************************************
**

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
>
----------------------------------------------------------------------------
------
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org
<mailto:openssl-users-bounces at openssl.org> > On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org> 
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 26/06/2020 00:47, mhkelley2017 at gmail.com
<mailto:mhkelley2017 at gmail.com>  wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or
64-bit version and which options, or environmental variables, or specific
PATH elements do I need to pay attention to in order to accomplish that?
> 
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
> 
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
> 
>
https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-pr
ompt-for-vs
> 
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
> 
>
https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio
-2017
> 
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
> 
> 
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10
environment *without* need for visual studio?
> 
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
> 
> 
> There are details in the newly rewritten instructions for Windows:
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
> 
> Matt
> 
> 
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks. 
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org
<mailto:openssl-users-bounces at openssl.org> > On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org> 
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, mhkelley2017 at gmail.com
<mailto:mhkelley2017 at gmail.com>  wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine
type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org
<mailto:openssl-users-bounces at openssl.org> > On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org> 
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
Behalf
>>> Of mhkelley2017 at gmail.com <mailto:mhkelley2017 at gmail.com> 
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS
tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked.
Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment
on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64,
thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/f53e2188/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26123 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/f53e2188/attachment-0001.png>

From matt at openssl.org  Fri Jun 26 15:55:41 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2020 16:55:41 +0100
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
Message-ID: <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> ******************************************************************************
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> ******************************************************************************
> 
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
> 
> Maybe we should add an FAQ section of common faults and how to fix them.
> 
> Matt
> 
> 
> 
> 
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> ----------------------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks. 
>>>
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>>>> Thanks! That helped, but I have two follow-ups.
>>>>
>>>> 1) To whom would I suggest minor changes to the available installation
>>>> instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
>>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>>> 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
>>>> Could Not Find
>>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>>> Stop.
>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>>> : return code '0x2'
>>>> Stop.
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>>>> Caswell
>>>> Sent: Thursday, June 25, 2020 12:15 PM
>>>> To: openssl-users at openssl.org
>>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>>
>>>>
>>>>
>>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>>> Of mhkelley2017 at gmail.com
>>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>>
>>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>
>>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>>
>>>> Note that using masm to compile OpenSSL is no longer supported by us
>>>> (although it might still work).
>>>>
>>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>>
>>>> If you use the Developer Studio command prompt (64-bit) it should have
>>>> all the environment variables set up already to find the various VS tools.
>>>>
>>>> Matt
>>>>
>>>>
>>>>>
>>>>>> Building with Visual Studio  2019 Community
>>>>>
>>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>>> maybe it's part of some optional component?
>>>>>
>>>>> In VS2017 Professional, which is what I have configured at the moment on
>>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>>> to VS's gratuitously complicated directory layout.
>>>>>
>>>>> --
>>>>> Michael Wojcik
>>>>> Distinguished Engineer, Micro Focus
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 

From mhkelley2017 at gmail.com  Fri Jun 26 16:01:56 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 10:01:56 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
 <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
Message-ID: <011a01d64bd3$1dfcae90$59f60bb0$@gmail.com>

Sadly, I'm pretty sure MSYS2 comes without perl.  At any rate, without some PATH element that has a perl, MSYS2 can't find one.

It has been a while since I installed MSYS2, and I no longer recall (or have good enough notes) whether I made a poor choice at installation time - but I can check that out.

Mike

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 9:56 AM
To: openssl-users at openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> ******************************************************************************
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> ******************************************************************************
> 
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
> 
> Maybe we should add an FAQ section of common faults and how to fix them.
> 
> Matt
> 
> 
> 
> 
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> ----------------------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks. 
>>>
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>>>> Thanks! That helped, but I have two follow-ups.
>>>>
>>>> 1) To whom would I suggest minor changes to the available installation
>>>> instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
>>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>>> 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
>>>> Could Not Find
>>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>>> Stop.
>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>>> : return code '0x2'
>>>> Stop.
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>>>> Caswell
>>>> Sent: Thursday, June 25, 2020 12:15 PM
>>>> To: openssl-users at openssl.org
>>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>>
>>>>
>>>>
>>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>>> Of mhkelley2017 at gmail.com
>>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>>
>>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>
>>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>>
>>>> Note that using masm to compile OpenSSL is no longer supported by us
>>>> (although it might still work).
>>>>
>>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>>
>>>> If you use the Developer Studio command prompt (64-bit) it should have
>>>> all the environment variables set up already to find the various VS tools.
>>>>
>>>> Matt
>>>>
>>>>
>>>>>
>>>>>> Building with Visual Studio  2019 Community
>>>>>
>>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>>> maybe it's part of some optional component?
>>>>>
>>>>> In VS2017 Professional, which is what I have configured at the moment on
>>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>>> to VS's gratuitously complicated directory layout.
>>>>>
>>>>> --
>>>>> Michael Wojcik
>>>>> Distinguished Engineer, Micro Focus
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 


From Michael.Wojcik at microfocus.com  Fri Jun 26 17:24:38 2020
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 26 Jun 2020 17:24:38 +0000
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <011a01d64bd3$1dfcae90$59f60bb0$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
 <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
 <011a01d64bd3$1dfcae90$59f60bb0$@gmail.com>
Message-ID: <DM6PR18MB2700FCE901A314A87C1C0252F9930@DM6PR18MB2700.namprd18.prod.outlook.com>

[Removed the top-posted mess of history from this reply.]

In response to various questions posed in this thread:

> Can someone point me to sources of information about how to resolve this issue?

Probably not, because it's not clear how you got into this state in the first place. You have a mix of 32- and 64-bit tools in your toolchain for this build. I don't know what you did to get there; I've never seen that happen with any of my OpenSSL builds.

> I simply don't believe I'm the only one who wants to build OpenSSL for use in a
> Windows 10 environment - someone must have been successful and be able to point
> me to additional information.

That's good, because that would be a silly thing to believe. We have multiple teams that routinely build OpenSSL for Windows (and other platforms). I've built it myself any number of times. We build both 32- and 64-bit variants, without problems.

My suggestion: Follow the recommended process by installing nasm (it's free) and configuring for that instead of MASM. As Matt suggested, start from a "Visual Studio Command Prompt" window for the bitness you want to build, and then make sure you configure for that bitness. Get rid of any existing build artifacts first - probably the easist way is to move your working directory aside and extract a fresh one from the tarball.

As Matt noted, you can confirm whether you're using the 32- or 64-bit version of the Visual Studio toolchain just by running cl.exe with no parameters; the banner says "for x86" or "for x64". Note that it's important to let Visual Studio set up the environment (using one of those "Visual Studio Command Prompt" options) rather than trying to set it up manually - the latter is possible (I do it for my Cygwin bash sessions), but it's a pain to get it right.

> I messed around quite a bit trying to figure out how I might modify the build
> process to work with my usual set of tools - mostly UNIX-tools ported to Windows
> environment.  My preference would be to find pointers to information of how to
> accomplish that.

Unless your usual set of tools matches what OpenSSL wants for the MinGW+MSYS2 configuration option, I'd strongly recommend not trying to do this unless and until you understand the OpenSSL build process very well.

Regarding MSYS2 and Perl:

- Did you read the updated NOTES.WIN that Matt posted a link to?

- Perl implementations for Windows vary widely in their idiosyncracies, and OpenSSL is finicky about them. For years we used Cygwin Perl, but had to run it under a wrapper program which altered the command-line arguments. These days, we use Strawberry Perl. ActiveState Perl has also worked, but has licensing issues when used to build commercial software; that probably doesn't apply in your case. Note Strawberry and ActiveState have Windows-native behavior, and thus can be expected to work for the Visual Studio configurations but probably not for the MSYS2 configurations.
   In my experience, getting Perl to cooperate is the biggest hurdle in building OpenSSL on Windows, and historically for us has been the most fragile aspect. As the OpenSSL build process has made heavier use of Perl, it's become more picky about getting a Perl it likes. (This is probably my least favorite aspect of OpenSSL. People complain about the OpenSSL source, but I'd much rather debug that than the Perl build scripts.)

- You haven't told us what Perl implementation you're using. Knowing the path to it doesn't help us. (Though, to be honest, knowing which implementation it is probably isn't terribly useful either.) It would be nice if Sergio told us which one *he's* using, since it's known to work with the MSYS2 configurations.

- I don't know whether there are Perl implementations for Windows specifically intended to be used with MinGW or MSYS2, and if so whether they work for the OpenSSL build. Oh, wait: I just did a quick search, and apparently there is an MSYS2 Perl package available from repo.msys2.org. Does it work with the OpenSSL build? I don't know, but it seems like it's worth a try.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


From mhkelley2017 at gmail.com  Fri Jun 26 17:34:46 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 11:34:46 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
 <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
Message-ID: <015001d64be0$15fe1960$41fa4c20$@gmail.com>

Thank you both, Matt and Sergio (and maybe Michael who just now weighed in but whose post I have not read).  You finally gave me clues sufficient to solve my problems. At present, OpenSSL is crunching through its tests and hasn't turned up a problem, so I think I can safely declare victory.

Thanks in particular to Sergio for giving me the assurance that OpenSSL *could* successfully build under Mingw-w6.
And thanks in particular to Matt for the key question that "It may well be that your MSYS2 environment already has perl available".

I simply re-installed MSYS2 and that solved all problem of which I was aware.

More complete response: I was running msys2-x86_64-20180531.exe, which I installed about 2 years ago.  Id *did not* include a version of perl.  It is hard to believe I would have deleted it, because that is a tool I use very frequently (though I'm generally in a standard windows command shell instead of MSYS2).  At some point, I installed and have relied on ActivePerl.

I deleted that version of MSYS2 and installed  msys2-base-x86_64-20200602.  This was a raw install - I still need to re-configure a bunch of add-on packages, but that is for later.  First thing I did after MSYS2 configured itself was re-run my build script - didn't change anything, just re-ran it.

Problem solved.

Again, thanks for sticking we me to success!

Mke


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 9:56 AM
To: openssl-users at openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> ******************************************************************************
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> ******************************************************************************
> 
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
> 
> Maybe we should add an FAQ section of common faults and how to fix them.
> 
> Matt
> 
> 
> 
> 
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> ----------------------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: openssl-users at openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, mhkelley2017 at gmail.com wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks. 
>>>
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, mhkelley2017 at gmail.com wrote:
>>>> Thanks! That helped, but I have two follow-ups.
>>>>
>>>> 1) To whom would I suggest minor changes to the available installation
>>>> instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
>>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>>> 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
>>>> Could Not Find
>>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>>> Stop.
>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>>> : return code '0x2'
>>>> Stop.
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
>>>> Caswell
>>>> Sent: Thursday, June 25, 2020 12:15 PM
>>>> To: openssl-users at openssl.org
>>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>>
>>>>
>>>>
>>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>>>> Of mhkelley2017 at gmail.com
>>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>>
>>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>
>>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>>
>>>> Note that using masm to compile OpenSSL is no longer supported by us
>>>> (although it might still work).
>>>>
>>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>>
>>>> If you use the Developer Studio command prompt (64-bit) it should have
>>>> all the environment variables set up already to find the various VS tools.
>>>>
>>>> Matt
>>>>
>>>>
>>>>>
>>>>>> Building with Visual Studio  2019 Community
>>>>>
>>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>>> maybe it's part of some optional component?
>>>>>
>>>>> In VS2017 Professional, which is what I have configured at the moment on
>>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>>> to VS's gratuitously complicated directory layout.
>>>>>
>>>>> --
>>>>> Michael Wojcik
>>>>> Distinguished Engineer, Micro Focus
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 


From mhkelley2017 at gmail.com  Fri Jun 26 18:09:22 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 12:09:22 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <DM6PR18MB2700FCE901A314A87C1C0252F9930@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
 <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
 <011a01d64bd3$1dfcae90$59f60bb0$@gmail.com>
 <DM6PR18MB2700FCE901A314A87C1C0252F9930@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <015f01d64be4$eb7e2db0$c27a8910$@gmail.com>


Thank you very much.  While my problem has already been resolved,
you raise a couple of issues that are worth noting for
completeness.

> > Can someone point me to sources of information about how to
> > resolve this issue?
> 
> Probably not, because it's not clear how you got into this state
> in the first place. You have a mix of 32- and 64-bit tools in
> your toolchain for this build. I don't know what you did to get
> there; I've never seen that happen with any of my OpenSSL builds.
> 
*** snip ***
> 
> My suggestion: Follow the recommended process by installing nasm
> (it's free) and configuring for that instead of MASM.

Did that as soon I decided to give up on mingw64 and try Visual
Studio.  Granted, my Y-chromosome does give me some challenges
when it comes to reading/following instructions, but that
requirement was clearly enough stated that I noticed and followed
up on it :)

> As Matt
> suggested, start from a "Visual Studio Command Prompt" window for
> the bitness you want to build, and then make sure you configure
> for that bitness. Get rid of any existing build artifacts first -
> probably the easist way is to move your working directory aside
> and extract a fresh one from the tarball.

Actualy repeated that step several times throughout to ensure I
was always starting clean.

> As Matt noted, you can confirm whether you're using the 32- or
> 64-bit version of the Visual Studio toolchain just by running
> cl.exe with no parameters; the banner says "for x86" or "for
> x64".

What cl.exe responded was what I expected, so didn't report it:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe

It is still a mystery why/how anything related to 32-bit ever arose in the build process.  But I no longer care because it was apparently self-inflicted and not likely to bother anyone else.

*** snip ***

> Regarding MSYS2 and Perl:
> 
> - Did you read the updated NOTES.WIN that Matt posted a link to?

Yes, found them at the beginning of my efforts, but (in case you
know the old joke about magicians), "the rabbit was already in
the hat" by that point.

*** snip ***

> - You haven't told us what Perl implementation you're
>   using.

My initial post:
   Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

>   Knowing the path to it doesn't help us. (Though, to be
>   honest, knowing which implementation it is probably isn't
>   terribly useful either.) It would be nice if Sergio told us
>   which one *he's* using, since it's known to work with the MSYS2
>   configurations.

I think he did tell is - implicitly.  He used whatever he has
installed with his MSYS2 package.  If I'd had the same one
installed with my package, I'd have missed all this fun.
> 
> - I don't know whether there are Perl implementations for Windows
>   specifically intended to be used with MinGW or MSYS2, and if so
>   whether they work for the OpenSSL build. Oh, wait: I just did a
>   quick search, and apparently there is an MSYS2 Perl package
>   available from repo.msys2.org. Does it work with the OpenSSL
>   build? I don't know, but it seems like it's worth a try.

This is actually an important question.  In response to Matt's
suggestion, I went to MSYS2 to see what packages they have.
Their list of packages *did not* include a choice like "the one
we include with our initial installation in case you have somehow
lost it". Instead, they list the two give in one of my more
recent posts.  One listed is explicitly designed for use with
mingw-64.  It fails for OpenSSL the same way as ActivePerl.

Bottom line:  MSYS2 *does* include perl in its basic installation
(at least the most recent version) and it works.  Don't mess that
one up or your in for some fun.

Thanks to all.


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael Wojcik
Sent: Friday, June 26, 2020 11:25 AM
To: openssl-users at openssl.org
Subject: RE: Error building OpenSSL-1.1.1g

[Removed the top-posted mess of history from this reply.]

In response to various questions posed in this thread:

> Can someone point me to sources of information about how to resolve this issue?

Probably not, because it's not clear how you got into this state in the first place. You have a mix of 32- and 64-bit tools in your toolchain for this build. I don't know what you did to get there; I've never seen that happen with any of my OpenSSL builds.

> I simply don't believe I'm the only one who wants to build OpenSSL for use in a
> Windows 10 environment - someone must have been successful and be able to point
> me to additional information.

That's good, because that would be a silly thing to believe. We have multiple teams that routinely build OpenSSL for Windows (and other platforms). I've built it myself any number of times. We build both 32- and 64-bit variants, without problems.

My suggestion: Follow the recommended process by installing nasm (it's free) and configuring for that instead of MASM. As Matt suggested, start from a "Visual Studio Command Prompt" window for the bitness you want to build, and then make sure you configure for that bitness. Get rid of any existing build artifacts first - probably the easist way is to move your working directory aside and extract a fresh one from the tarball.

As Matt noted, you can confirm whether you're using the 32- or 64-bit version of the Visual Studio toolchain just by running cl.exe with no parameters; the banner says "for x86" or "for x64". Note that it's important to let Visual Studio set up the environment (using one of those "Visual Studio Command Prompt" options) rather than trying to set it up manually - the latter is possible (I do it for my Cygwin bash sessions), but it's a pain to get it right.

> I messed around quite a bit trying to figure out how I might modify the build
> process to work with my usual set of tools - mostly UNIX-tools ported to Windows
> environment.  My preference would be to find pointers to information of how to
> accomplish that.

Unless your usual set of tools matches what OpenSSL wants for the MinGW+MSYS2 configuration option, I'd strongly recommend not trying to do this unless and until you understand the OpenSSL build process very well.

Regarding MSYS2 and Perl:

- Did you read the updated NOTES.WIN that Matt posted a link to?

- Perl implementations for Windows vary widely in their idiosyncracies, and OpenSSL is finicky about them. For years we used Cygwin Perl, but had to run it under a wrapper program which altered the command-line arguments. These days, we use Strawberry Perl. ActiveState Perl has also worked, but has licensing issues when used to build commercial software; that probably doesn't apply in your case. Note Strawberry and ActiveState have Windows-native behavior, and thus can be expected to work for the Visual Studio configurations but probably not for the MSYS2 configurations.
   In my experience, getting Perl to cooperate is the biggest hurdle in building OpenSSL on Windows, and historically for us has been the most fragile aspect. As the OpenSSL build process has made heavier use of Perl, it's become more picky about getting a Perl it likes. (This is probably my least favorite aspect of OpenSSL. People complain about the OpenSSL source, but I'd much rather debug that than the Perl build scripts.)

- You haven't told us what Perl implementation you're using. Knowing the path to it doesn't help us. (Though, to be honest, knowing which implementation it is probably isn't terribly useful either.) It would be nice if Sergio told us which one *he's* using, since it's known to work with the MSYS2 configurations.

- I don't know whether there are Perl implementations for Windows specifically intended to be used with MinGW or MSYS2, and if so whether they work for the OpenSSL build. Oh, wait: I just did a quick search, and apparently there is an MSYS2 Perl package available from repo.msys2.org. Does it work with the OpenSSL build? I don't know, but it seems like it's worth a try.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From mhkelley2017 at gmail.com  Fri Jun 26 20:20:07 2020
From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com)
Date: Fri, 26 Jun 2020 14:20:07 -0600
Subject: Error building OpenSSL-1.1.1g
In-Reply-To: <015f01d64be4$eb7e2db0$c27a8910$@gmail.com>
References: <022a01d64b11$3d237730$b76a6590$@gmail.com>
 <DM6PR18MB270008BE8A98C0E10FD0B1EDF9920@DM6PR18MB2700.namprd18.prod.outlook.com>
 <0106688d-24ff-21dc-a5c9-8ddead5d72db@openssl.org>
 <03d301d64b25$a3348690$e99d93b0$@gmail.com>
 <b4248980-e723-a86d-dd67-38d67a28683a@openssl.org>
 <03fe01d64b4a$f5b4d3a0$e11e7ae0$@gmail.com>
 <0eefda46-343b-0fca-baeb-810abe2d7c1e@openssl.org>
 <00bc01d64bbd$7cf520f0$76df62d0$@gmail.com>
 <b30f3a49-532d-ab0e-ccf1-725fc69c7414@openssl.org>
 <99389d20-7324-d0d9-c06f-8504ae9af247@openssl.org>
 <011a01d64bd3$1dfcae90$59f60bb0$@gmail.com>
 <DM6PR18MB2700FCE901A314A87C1C0252F9930@DM6PR18MB2700.namprd18.prod.outlook.com>
 <015f01d64be4$eb7e2db0$c27a8910$@gmail.com>
Message-ID: <018201d64bf7$2fd43510$8f7c9f30$@gmail.com>

Two follow-up issues - someone please tell me if I should have started a new thread - these are not really related to the initial point of this one.

While my build and test worked after re-installing MSYS2, the install failed.  Unfortunately I inadvertently over-wrote the logfile I was keeping about this thread.

1) OPENSSLDIR was not correctly set.  In essence, while the documentation leads one to assume that the configure option --openssldir is derived from --prefix, this was NOT the case.  All of the installs went into the PREFIX I had passed to Configure until something barfed when it tried to write to c:\Program Files\SSL.  I then re-configured/re-built with both --prefix=PREFIX and --openssldir=PReFIX/SSL specified.  This seems to have worked correctly, with the relevant files then being put where they should be.

Perhaps this should be reported as a possible bug in the build process?

2) The documentation was not successfully installed.  There appears to be a complete file tree for it, but all of the html files are empty.  The failure is:

/c/usr/local/OPENSSL/openssl-1.1.1g/x86_64-8.1.0-posix-seh-rt_v6-rev0/share/doc/openssl/html/man7/X448.html -> /c/usr/local/OPENSSL/openssl-1.1.1g/x86_64-8.1.0-posix-seh-rt_v6-rev0/share/doc/openssl/html/man7/X25519.html
sh: pod2html: command not found

pod2html is a perl script in C:\msys64\usr\bin\core_perl.  I added that to my PATH.

Because I never saw any suggestion to do so, this might also be more appropriately submitted as a potential bug in the build process.



-----Original Message-----
From: mhkelley2017 at gmail.com <mhkelley2017 at gmail.com> 
Sent: Friday, June 26, 2020 12:09 PM
To: openssl-users at openssl.org
Cc: 'Michael Wojcik' <Michael.Wojcik at microfocus.com>
Subject: RE: Error building OpenSSL-1.1.1g


Thank you very much.  While my problem has already been resolved,
you raise a couple of issues that are worth noting for
completeness.

> > Can someone point me to sources of information about how to
> > resolve this issue?
> 
> Probably not, because it's not clear how you got into this state
> in the first place. You have a mix of 32- and 64-bit tools in
> your toolchain for this build. I don't know what you did to get
> there; I've never seen that happen with any of my OpenSSL builds.
> 
*** snip ***
> 
> My suggestion: Follow the recommended process by installing nasm
> (it's free) and configuring for that instead of MASM.

Did that as soon I decided to give up on mingw64 and try Visual
Studio.  Granted, my Y-chromosome does give me some challenges
when it comes to reading/following instructions, but that
requirement was clearly enough stated that I noticed and followed
up on it :)

> As Matt
> suggested, start from a "Visual Studio Command Prompt" window for
> the bitness you want to build, and then make sure you configure
> for that bitness. Get rid of any existing build artifacts first -
> probably the easist way is to move your working directory aside
> and extract a fresh one from the tarball.

Actualy repeated that step several times throughout to ensure I
was always starting clean.

> As Matt noted, you can confirm whether you're using the 32- or
> 64-bit version of the Visual Studio toolchain just by running
> cl.exe with no parameters; the banner says "for x86" or "for
> x64".

What cl.exe responded was what I expected, so didn't report it:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe

It is still a mystery why/how anything related to 32-bit ever arose in the build process.  But I no longer care because it was apparently self-inflicted and not likely to bother anyone else.

*** snip ***

> Regarding MSYS2 and Perl:
> 
> - Did you read the updated NOTES.WIN that Matt posted a link to?

Yes, found them at the beginning of my efforts, but (in case you
know the old joke about magicians), "the rabbit was already in
the hat" by that point.

*** snip ***

> - You haven't told us what Perl implementation you're
>   using.

My initial post:
   Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

>   Knowing the path to it doesn't help us. (Though, to be
>   honest, knowing which implementation it is probably isn't
>   terribly useful either.) It would be nice if Sergio told us
>   which one *he's* using, since it's known to work with the MSYS2
>   configurations.

I think he did tell is - implicitly.  He used whatever he has
installed with his MSYS2 package.  If I'd had the same one
installed with my package, I'd have missed all this fun.
> 
> - I don't know whether there are Perl implementations for Windows
>   specifically intended to be used with MinGW or MSYS2, and if so
>   whether they work for the OpenSSL build. Oh, wait: I just did a
>   quick search, and apparently there is an MSYS2 Perl package
>   available from repo.msys2.org. Does it work with the OpenSSL
>   build? I don't know, but it seems like it's worth a try.

This is actually an important question.  In response to Matt's
suggestion, I went to MSYS2 to see what packages they have.
Their list of packages *did not* include a choice like "the one
we include with our initial installation in case you have somehow
lost it". Instead, they list the two give in one of my more
recent posts.  One listed is explicitly designed for use with
mingw-64.  It fails for OpenSSL the same way as ActivePerl.

Bottom line:  MSYS2 *does* include perl in its basic installation
(at least the most recent version) and it works.  Don't mess that
one up or your in for some fun.

Thanks to all.


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael Wojcik
Sent: Friday, June 26, 2020 11:25 AM
To: openssl-users at openssl.org
Subject: RE: Error building OpenSSL-1.1.1g

[Removed the top-posted mess of history from this reply.]

In response to various questions posed in this thread:

> Can someone point me to sources of information about how to resolve this issue?

Probably not, because it's not clear how you got into this state in the first place. You have a mix of 32- and 64-bit tools in your toolchain for this build. I don't know what you did to get there; I've never seen that happen with any of my OpenSSL builds.

> I simply don't believe I'm the only one who wants to build OpenSSL for use in a
> Windows 10 environment - someone must have been successful and be able to point
> me to additional information.

That's good, because that would be a silly thing to believe. We have multiple teams that routinely build OpenSSL for Windows (and other platforms). I've built it myself any number of times. We build both 32- and 64-bit variants, without problems.

My suggestion: Follow the recommended process by installing nasm (it's free) and configuring for that instead of MASM. As Matt suggested, start from a "Visual Studio Command Prompt" window for the bitness you want to build, and then make sure you configure for that bitness. Get rid of any existing build artifacts first - probably the easist way is to move your working directory aside and extract a fresh one from the tarball.

As Matt noted, you can confirm whether you're using the 32- or 64-bit version of the Visual Studio toolchain just by running cl.exe with no parameters; the banner says "for x86" or "for x64". Note that it's important to let Visual Studio set up the environment (using one of those "Visual Studio Command Prompt" options) rather than trying to set it up manually - the latter is possible (I do it for my Cygwin bash sessions), but it's a pain to get it right.

> I messed around quite a bit trying to figure out how I might modify the build
> process to work with my usual set of tools - mostly UNIX-tools ported to Windows
> environment.  My preference would be to find pointers to information of how to
> accomplish that.

Unless your usual set of tools matches what OpenSSL wants for the MinGW+MSYS2 configuration option, I'd strongly recommend not trying to do this unless and until you understand the OpenSSL build process very well.

Regarding MSYS2 and Perl:

- Did you read the updated NOTES.WIN that Matt posted a link to?

- Perl implementations for Windows vary widely in their idiosyncracies, and OpenSSL is finicky about them. For years we used Cygwin Perl, but had to run it under a wrapper program which altered the command-line arguments. These days, we use Strawberry Perl. ActiveState Perl has also worked, but has licensing issues when used to build commercial software; that probably doesn't apply in your case. Note Strawberry and ActiveState have Windows-native behavior, and thus can be expected to work for the Visual Studio configurations but probably not for the MSYS2 configurations.
   In my experience, getting Perl to cooperate is the biggest hurdle in building OpenSSL on Windows, and historically for us has been the most fragile aspect. As the OpenSSL build process has made heavier use of Perl, it's become more picky about getting a Perl it likes. (This is probably my least favorite aspect of OpenSSL. People complain about the OpenSSL source, but I'd much rather debug that than the Perl build scripts.)

- You haven't told us what Perl implementation you're using. Knowing the path to it doesn't help us. (Though, to be honest, knowing which implementation it is probably isn't terribly useful either.) It would be nice if Sergio told us which one *he's* using, since it's known to work with the MSYS2 configurations.

- I don't know whether there are Perl implementations for Windows specifically intended to be used with MinGW or MSYS2, and if so whether they work for the OpenSSL build. Oh, wait: I just did a quick search, and apparently there is an MSYS2 Perl package available from repo.msys2.org. Does it work with the OpenSSL build? I don't know, but it seems like it's worth a try.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From levitte at openssl.org  Fri Jun 26 21:13:20 2020
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 26 Jun 2020 23:13:20 +0200
Subject: OpenSSL 1.1.1g test failures
In-Reply-To: <5EF5FFA5.24568.C5F7E5FB@openssl.pmail.gen.nz>
References: <5EF5C3D4.17497.C50E3BE2@openssl.pmail.gen.nz>
Message-ID: <87zh8pil8v.wl-levitte@openssl.org>

On Fri, 26 Jun 2020 16:01:09 +0200,
David Harris wrote:
> Is there a standard (i.e, approved) way of using the static RTLs instead of the 
> DLL ones? Or is my only option to modify the applink code so that it checks its 
> environment in a different way? The problem with the dynamic RTLs is that my 
> application is often used in environments where the user may not have sufficient 
> rights to install the redistributables - whereas, if I use the static versions, the 
> code is a little bigger, but there's no redistributable installation required and I 
> never run into rights issues.

The standard way of getting /MT is to configure 'no-shared', i.e. not
produce DLLs.

    perl Configure VC-WIN64A no-shared

However, if the main issue is *your* application, then the simplest
way is to link with the static library, regardless of configuration.
We do produce alongside static libraries alongside the DLLs since
1.1.1: libcrypto_static.lib.

Cheers,
Richard

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

From openssl at pmail.gen.nz  Sun Jun 28 03:12:39 2020
From: openssl at pmail.gen.nz (David Harris)
Date: Sun, 28 Jun 2020 15:12:39 +1200
Subject: NASM virus issues.
Message-ID: <5EF80AA7.5334.CDF2F457@openssl.pmail.gen.nz>

I normally compile OpenSSL with "no-asm", but this time I thought I'd try 
installing NASM and seeing what difference, if any, it actually made.

I downloaded NASM from the official site (which I believe to be 
http://www.nasm.us) and, as I always do with anything I source from outside my 
firewall, ran it through virustotal (https://www.virustotal.com/gui/home/upload).

It reports 11 different scanners out of 72 finding malware in the file 
(nasm-2.15.01-installer-x86.exe). Now, one or two reports from Virustotal is 
normal - there are so many scanners out there that there are bound to be 
occasional false-positives... But 11 is more than I have ever seen on something 
that supposedly wasn't infected. Interestingly, VirusTotal did not have cached 
results for this file, meaning that nobody else has tested it in the last month or 
so.

Google didn't reveal any insight, and the NASM project doesn't have any contact 
options that don't involve registration or mailing lists or I'd report this to them. 
There is no mention of anything like this in their forum.

11 reports is too many for me to feel safe using this product, so for now I'll keep 
using no-asm, and hope that it's not going to get more deprecated than it 
apparently is at present (based on the comments in INSTALL).

If anyone on the list has a NASM account or knows any of the maintainers, 
could they pass this on? They really should be aware of it.

Cheers!

-- David --


From sys.admin at xn--zhxu-cloud-c7ac.eu  Sun Jun 28 14:37:35 2020
From: sys.admin at xn--zhxu-cloud-c7ac.eu (=?utf-8?Q?Net-_=26_System-_Administration_from_NeuroScience_of_Zh?= =?utf-8?Q?=C3=A9xu=C3=A9-Cloud?=)
Date: Sun, 28 Jun 2020 16:37:35 +0200
Subject: Question about OpenSSL .....
Message-ID: <36AAC409-19C8-49B1-BDD2-B99AA145F53E@xn--zhxu-cloud-c7ac.eu>

Hello together,

I am new here on this list and I have a question about OpenSSL.

On my system (Debian 10 - Buster) is OpenSSL installed with Version 1.1.
Now, I want to install OpenSSL 3.x, but which is the best way for that?

Deinstall the old one, or?


Best regards 


Zh?xu? M.

From nic.tuv at gmail.com  Sun Jun 28 14:56:05 2020
From: nic.tuv at gmail.com (Nicola Tuveri)
Date: Sun, 28 Jun 2020 16:56:05 +0200
Subject: Question about OpenSSL .....
In-Reply-To: <36AAC409-19C8-49B1-BDD2-B99AA145F53E@xn--zhxu-cloud-c7ac.eu>
References: <36AAC409-19C8-49B1-BDD2-B99AA145F53E@xn--zhxu-cloud-c7ac.eu>
Message-ID: <CANm5x_Np=gFiqrcNpZN1L4_jY-6_zqTJHMnXMTZKaDvOJ_k_Vg@mail.gmail.com>

Hello and welcome!

> On my system (Debian 10 - Buster) is OpenSSL installed with Version 1.1.
> Now, I want to install OpenSSL 3.x, but which is the best way for that?
>
> Deinstall the old one, or?

First, keep in mind that 3.x is still in alpha development stage, so
using it as the system-wide library is not at all recommended.

Even after 3.0 will be released officially, replacing the system wide
installation of OpenSSL provided by your Linux distribution is a very
risky business, as many of the required and optional binary packages
the distribution provides are depending on the version of `libcrypto`
and `libssl` shipped within the official OpenSSL packages from your
distribution.

The recommended thing to do when you want to build applications from
sources to use a different version of OpenSSL than what is shipped
with your distribution is to have a custom installation of OpenSSL
(somewhere outside of your linker default path).

You can read more about it on the NOTES.UNIX file in your source
tarball, or at https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.UNIX
.

Note the link above is from the 1.1.1 stable branch, as in master soon
it will likely be replaced with a markdown version of the same file
(PR #12109): you can see a preview of the markdown version of it at
https://github.com/openssl/openssl/blob/be101175badd30402d2e480a79e98ade1343cbfd/NOTES-Unix.md
but beware this link is likely going to be broken at some point after
the PR is merged (but at that point you will be able to find the same
file in `master`).


Hope this helps!


Best regards,

Nicola Tuveri

From nic.tuv at gmail.com  Sun Jun 28 15:03:08 2020
From: nic.tuv at gmail.com (Nicola Tuveri)
Date: Sun, 28 Jun 2020 17:03:08 +0200
Subject: Question about OpenSSL .....
In-Reply-To: <CANm5x_Np=gFiqrcNpZN1L4_jY-6_zqTJHMnXMTZKaDvOJ_k_Vg@mail.gmail.com>
References: <36AAC409-19C8-49B1-BDD2-B99AA145F53E@xn--zhxu-cloud-c7ac.eu>
 <CANm5x_Np=gFiqrcNpZN1L4_jY-6_zqTJHMnXMTZKaDvOJ_k_Vg@mail.gmail.com>
Message-ID: <CANm5x_NKqJ8U7R5Bshbdqr1n=eCUCs9D2a8baceDmACztA10ew@mail.gmail.com>

Sorry,

I forgot to include also a link to INSTALL.md

I am linking the preview from PR#12109 again, as it has been improved
to leverage Markdown formatting to be more readable:

https://github.com/openssl/openssl/blob/be101175badd30402d2e480a79e98ade1343cbfd/INSTALL.md#installing-openssl


Same caveat as before: at some point the link above will likely be
broken once the PR is merged, but the updated INSTALL.md file will be
available at

https://github.com/openssl/openssl/blob/master/INSTALL.md#installing-openssl

On Sun, 28 Jun 2020 at 16:56, Nicola Tuveri <nic.tuv at gmail.com> wrote:
>
> Hello and welcome!
>
> > On my system (Debian 10 - Buster) is OpenSSL installed with Version 1.1.
> > Now, I want to install OpenSSL 3.x, but which is the best way for that?
> >
> > Deinstall the old one, or?
>
> First, keep in mind that 3.x is still in alpha development stage, so
> using it as the system-wide library is not at all recommended.
>
> Even after 3.0 will be released officially, replacing the system wide
> installation of OpenSSL provided by your Linux distribution is a very
> risky business, as many of the required and optional binary packages
> the distribution provides are depending on the version of `libcrypto`
> and `libssl` shipped within the official OpenSSL packages from your
> distribution.
>
> The recommended thing to do when you want to build applications from
> sources to use a different version of OpenSSL than what is shipped
> with your distribution is to have a custom installation of OpenSSL
> (somewhere outside of your linker default path).
>
> You can read more about it on the NOTES.UNIX file in your source
> tarball, or at https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.UNIX
> .
>
> Note the link above is from the 1.1.1 stable branch, as in master soon
> it will likely be replaced with a markdown version of the same file
> (PR #12109): you can see a preview of the markdown version of it at
> https://github.com/openssl/openssl/blob/be101175badd30402d2e480a79e98ade1343cbfd/NOTES-Unix.md
> but beware this link is likely going to be broken at some point after
> the PR is merged (but at that point you will be able to find the same
> file in `master`).
>
>
> Hope this helps!
>
>
> Best regards,
>
> Nicola Tuveri

From tmraz at redhat.com  Mon Jun 29 06:41:12 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 29 Jun 2020 08:41:12 +0200
Subject: NASM virus issues.
In-Reply-To: <5EF80AA7.5334.CDF2F457@openssl.pmail.gen.nz>
References: <5EF80AA7.5334.CDF2F457@openssl.pmail.gen.nz>
Message-ID: <eeafff8329bc9d08f496d367321a00138b20464d.camel@redhat.com>

On Sun, 2020-06-28 at 15:12 +1200, David Harris wrote:
> I normally compile OpenSSL with "no-asm", but this time I thought I'd
> try 
> installing NASM and seeing what difference, if any, it actually made.
> 
> I downloaded NASM from the official site (which I believe to be 
> http://www.nasm.us) and, as I always do with anything I source from
> outside my 
> firewall, ran it through virustotal (
> https://www.virustotal.com/gui/home/upload).
> 
> It reports 11 different scanners out of 72 finding malware in the
> file 
> (nasm-2.15.01-installer-x86.exe). Now, one or two reports from
> Virustotal is 
> normal - there are so many scanners out there that there are bound to
> be 
> occasional false-positives... But 11 is more than I have ever seen on
> something 
> that supposedly wasn't infected. Interestingly, VirusTotal did not
> have cached 
> results for this file, meaning that nobody else has tested it in the
> last month or 
> so.
> 
> Google didn't reveal any insight, and the NASM project doesn't have
> any contact 
> options that don't involve registration or mailing lists or I'd
> report this to them. 
> There is no mention of anything like this in their forum.
> 
> 11 reports is too many for me to feel safe using this product, so for
> now I'll keep 
> using no-asm, and hope that it's not going to get more deprecated
> than it 
> apparently is at present (based on the comments in INSTALL).
> 
> If anyone on the list has a NASM account or knows any of the
> maintainers, 
> could they pass this on? They really should be aware of it.

I'd recommend reporting your findings to the NASM bugzilla 
http://bugzilla.nasm.us/ or to their forum at 
https://forum.nasm.us/

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From nashley at cisco.com  Fri Jun 12 19:00:29 2020
From: nashley at cisco.com (Norman Ashley (nashley))
Date: Fri, 12 Jun 2020 19:00:29 -0000
Subject: genrsa: unable to load provider fips
Message-ID: <0A408F3C-B181-41FF-BDFF-D344D90A6108@cisco.com>

Running apps/openssl genrsa -provider fips results in the following error ?
genrsa: unable to load provider fips
C0FDC40A01000000:error::common libcrypto routines:provider_activate:init fail:crypto/provider_core.c:503:

What am I missing?
Thanks,
Norman



perl configdata.pm --dump

Command line (with current working directory = .):

    perl ./Configure darwin64-x86_64-cc --prefix=/Downloads/ossl-3-install --openssldir=/Downloads/ossl-3-install/ssl --debug

Perl information:

    perl
    5.18.4 for darwin-thread-multi-2level

Enabled features:

    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    camellia
    capieng
    cast
    chacha
    cmac
    cmp
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    fips
    gost
    idea
    legacy
    makedepend
    md4
    mdc2
    module
    multiblock
    nextprotoneg
    pinshared
    ocb
    ocsp
    padlockeng
    pic
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    secure-memory
    seed
    shared
    siphash
    siv
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    static-engine
    stdio
    tests
    threads
    tls
    ts
    ui-console
    whirlpool
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method

Disabled features:

    afalgeng            [not-linux]      OPENSSL_NO_AFALGENG
    asan                [default]        OPENSSL_NO_ASAN
    buildtest-c++       [default]
    crypto-mdebug       [default]        OPENSSL_NO_CRYPTO_MDEBUG
    devcryptoeng        [default]        OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128 [default]        OPENSSL_NO_EC_NISTP_64_GCC_128
    egd                 [default]        OPENSSL_NO_EGD
    external-tests      [default]        OPENSSL_NO_EXTERNAL_TESTS
    fuzz-libfuzzer      [default]        OPENSSL_NO_FUZZ_LIBFUZZER
    fuzz-afl            [default]        OPENSSL_NO_FUZZ_AFL
    ktls                [default]        OPENSSL_NO_KTLS
    md2                 [default]        OPENSSL_NO_MD2 (skip crypto/md2)
    msan                [default]        OPENSSL_NO_MSAN
    rc5                 [default]        OPENSSL_NO_RC5 (skip crypto/rc5)
    sctp                [default]        OPENSSL_NO_SCTP
    ssl-trace           [default]        OPENSSL_NO_SSL_TRACE
    trace               [default]        OPENSSL_NO_TRACE
    ubsan               [default]        OPENSSL_NO_UBSAN
    unit-test           [default]        OPENSSL_NO_UNIT_TEST
    uplink              [no uplink_arch] OPENSSL_NO_UPLINK
    weak-ssl-ciphers    [default]        OPENSSL_NO_WEAK_SSL_CIPHERS
    zlib                [default]
    zlib-dynamic        [default]
    ssl3                [default]        OPENSSL_NO_SSL3
    ssl3-method         [default]        OPENSSL_NO_SSL3_METHOD

Config target attributes:

    AR => "ar",
    ARFLAGS => "r",
    CC => "cc",
    CFLAGS => "-g -O0 -Wall",
    HASHBANGPERL => "/usr/bin/env perl",
    RANLIB => "ranlib -c",
    RC => "windres",
    asm_arch => "x86_64",
    bn_ops => "SIXTY_FOUR_BIT_LONG",
    build_file => "Makefile",
    build_scheme => [ "unified", "unix" ],
    cflags => "-arch x86_64",
    cppflags => "-D_REENTRANT",
    defines => [ "OPENSSL_BUILDING_OPENSSL" ],
    disable => [  ],
    dso_scheme => "dlfcn",
    enable => [  ],
    includes => [  ],
    lflags => "-Wl,-search_paths_first",
    lib_cflags => "",
    lib_cppflags => "-DL_ENDIAN",
    lib_defines => [  ],
    module_cflags => "-fPIC",
    module_cxxflags => undef,
    module_ldflags => "-bundle",
    perl_platform => "Unix",
    perlasm_scheme => "macosx",
    shared_cflag => "-fPIC",
    shared_defines => [  ],
    shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib",
    shared_ldflag => "-dynamiclib -current_version \$(SHLIB_VERSION_NUMBER) -compatibility_version \$(SHLIB_VERSION_NUMBER)",
    shared_rcflag => "",
    shared_sonameflag => "-install_name \$(INSTALLTOP)/\$(LIBDIR)/",
    shared_target => "darwin-shared",
    sys_id => "MACOSX",
    thread_defines => [  ],
    thread_scheme => "pthreads",
    unistd => "<unistd.h>",

Recorded environment:

    AR =
    ARFLAGS =
    AS =
    ASFLAGS =
    BUILDFILE =
    CC =
    CFLAGS =
    CPP =
    CPPDEFINES =
    CPPFLAGS =
    CPPINCLUDES =
    CROSS_COMPILE =
    CXX =
    CXXFLAGS =
    HASHBANGPERL =
    LD =
    LDFLAGS =
    LDLIBS =
    MT =
    MTFLAGS =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    RCFLAGS =
    RM =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = ar
    ARFLAGS         = r
    CC              = cc
    CFLAGS          = -g -O0 -Wall
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        =
    HASHBANGPERL    = /usr/bin/env perl
    LDFLAGS         =
    LDLIBS          =
    PERL            = perl
    RANLIB          = ranlib -c
    RC              = windres
    RCFLAGS         =

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
    Makefile

build file:

    Makefile

build file templates:

    Configurations/common0.tmpl
    Configurations/unix-Makefile.tmpl
    Configurations/common.tmpl


==========================================================

apps/openssl fipsinstall -out /Downloads/ossl-3-install/ssl/fipsmodule.cnf -module /Downloads/ossl-3-install/lib/ossl-modules/fips.dylib -provider_name fips -mac_name HMAC -macopt digest:SHA256 -macopt hexkey:00 -section_name fips_sect
HMAC : (Module_Integrity) : Pass
SHA1 : (KAT_Digest) : Pass
SHA2 : (KAT_Digest) : Pass
SHA3 : (KAT_Digest) : Pass
TDES : (KAT_Cipher) : Pass
AES_GCM : (KAT_Cipher) : Pass
RSA : (KAT_Signature) : Pass
ECDSA : (KAT_Signature) : Pass
DSA : (KAT_Signature) : Pass
HKDF : (KAT_KDF) : Pass
SSKDF : (KAT_KDF) : Pass
HASH : (DRBG) : Pass
CTR : (DRBG) : Pass
HMAC : (DRBG) : Pass
DH : (KAT_KA) : Pass
ECDH : (KAT_KA) : Pass
INSTALL PASSED


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200612/5aa2b190/attachment-0001.html>

From abaci.mjm at gmail.com  Tue Jun 30 19:25:14 2020
From: abaci.mjm at gmail.com (Michael Mueller)
Date: Tue, 30 Jun 2020 15:25:14 -0400
Subject: manual edit: i2d_PKCS7_bio
Message-ID: <CAND81pH5FMtCHhDpmSyroqXoww=djtqrT_SY74c9C4AwdAg5iQ@mail.gmail.com>

https://www.openssl.org/docs/man1.1.1/man3/i2d_PKCS7_bio.html

current:

i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of the
structure a to BIO bp and it returns 1 for success and 0 for failure.

Suggested edit:

i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of the
structure a to FILE pointer fp and it returns 1 for success and 0 for
failure.

 Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200630/7a648cfd/attachment.html>