Re: OpenSSL FIPS certificate #4282

[Dr Paul Dale]

A good question.

In a nut shell: the 3.0.0 FIPS provider is designed to work with all 
3.0.x releases.  We actively test this as part of our CI loops and it's 
the way to claim FIPS compliance when using OpenSSL 3.0.7.  You need to 
build 3.0.7 (with or without FIPS support) and the 3.0.0 FIPS provider 
(as per the security policy instructions) and then use the 3.0.0 FIPS 
provider with 3.0.7.


It is true that there have been fixes inside the FIPS boundary.  The 
project needs to individually assess each (well our validation lab has 
to).  Not all of these fixes are security relevant, not all are relevant 
to the validated code but some are.  The kind of change and its impact 
determine the method we use to update the validation (1-sub or 3-sub).  
We do plan on updating the validated version from time to time but it 
takes effort which has to be diverted from other tasks and FIPS changes 
tend towards glacial movement rates at the best of times.  It simply 
isn't practical to update the validation with every release.


There is a fast track available for severe CVEs and we would utilise 
this if required.  Currently, we are not aware of any bugs that would 
justify such treatment.  As far as I remember, they are either 
theoretical, difficult to trigger or out of scope.



Pauli


On 23/11/22 12:12, Thomas Dwyer III wrote:
The OpenSSL project has obtained certificate #4282 
 
from NIST for the FIPS provider. Nice. However, the certificate and 
accompanying security policy specifically list version 3.0.0 while the 
current release is 3.0.7. There have been CVEs & bugfixes since the 
3.0.0 release but it's not clear whether any of those directly 
affected the FIPS provider. Can someone from the OpenSSL project 
comment on the viability/suitability of using the 3.0.0 FIPS provider 
with a 3.0.7 libcrypto/libssl?



Thanks,
Tom.III

Re: Quantum-Resistant Cryptographic Algorithms

[Dr Paul Dale]

The project will once they are formally standardised.

In the meantime, the Open Quantum Safe project has a provider that 
implements all of the candidate algorithms 
(https://github.com/open-quantum-safe/oqs-provider).



Pauli

On 1/11/22 15:14, ad...@redtile.com wrote:
Will OpenSSL persue/support the four new NIST Quantum Cryptographic 
Algorithms?


https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms 

Re: Forthcoming OpenSSL Bug Fix Release

[Dr Paul Dale]

1.1.1 is not susceptible to the CVE that is being fixed in 3.0:

   /the forthcoming release of OpenSSL version 1.1.1s that is a *bug
   fix* release/.

(highlight added).


Dr Paul Dale

On 26/10/22 22:17, Matan Giladi wrote:

Does 1.1.1s is going to include any security fix?
Can you please confirm that the critical issue found in 3.0.6 version is 
irrelevant for 1.1.1?

-Original Message-
From: openssl-announce  On Behalf Of Ing. 
Martin Koci, MBA
Sent: Tuesday, October 25, 2022 21:36
To:openssl-annou...@openssl.org;openssl-users@openssl.org;openssl-proj...@openssl.org;oss-secur...@lists.openwall.com
Subject: Forthcoming OpenSSL Bug Fix Release

Hello,

In addition to the already announced 3.0.7 release, the OpenSSL project team 
would like to announce the forthcoming release of OpenSSL version 1.1.1s that 
is a bug fix release.

This bug fix release will be made available on Tuesday 1st November 2022 
between 1300-1700 UTC too.

Yours
The OpenSSL Project Team


Email secured by Check Point
Report 
Phishing:https://mta-cnf.iaas.checkpoint.com/mta_feedback?id=b3dc9e6004806fac5adb86a1a47504d00416eb2590b631502621736f0652d7ea=3D4CC6C8CB55;48DE55E160E5;C5CEAA199888;=m

Email secured by Check Point

Re: Using des-cbc in 3.0

[Dr Paul Dale]

Sam, it looks like you figured it out.

You don't need the "provider=legacy" in the EVP_CIPHER_fetch call, it 
will be found without this.



Pauli

On 24/5/22 08:38, Sam Varshavchik wrote:
I'm looking for an example of using des-cbc in openssl 3.0, I think I 
figured it out, but I'm not certain. I'm having trouble finding 
documentation, and the best kind of documentation is, of course, code.


I have existing code that uses EVP_des_cbc() followed by 
EVP_EncryptInit_ex().


It still compiles without issues, EVP_des_cbc() still works, then 
EVP_EncryptInit_ex fails.


I found 
https://github.com/openssl/openssl/blob/master/doc/man7/migration_guide.pod#Legacy-Algorithms


It directs me to OSSL_PROVIDER-legacy(7), which talks about 
EVP_CIPHER_fetch() and


# … has this property defined:
#
#   "provider=legacy"

I then see the following example in crypto(7):

# EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, "AES-128-CBC", NULL);

so I tried:

EVP_CIPHER *des=EVP_CIPHER_fetch(NULL, "DES-CBC", "provider=legacy");

which got me a NULL. After reading some more, I call

OSSL_PROVIDER_load(NULL, "legacy");

up front. The next thing that happened is all my SSL_CTX_new 
immediately exploded. So, then I also added an explicit call to


OSSL_PROVIDER_load(NULL, "default");

in addition that one. This /seems/ to work, and everything else that 
the code is doing, seems to work, but I don't feel like I'm on solid 
footing.  Did I miss some important detail that's going to bite me in 
the arse?

Re: RSA and DES encryption and decryption with C++ on Windows

[Dr Paul Dale]

Thanks Matthias, that's exactly what I did.  Too many repositories :)

Pauli



On 12/4/22 05:24, Dr. Matthias St. Pierre wrote:


Pauli accidentally posted a link to our internal repository. You can 
jost replace githuib.openssl.org by github.com:


https://github.com/openssl/openssl/tree/master/demos/encrypt

Matthias

*From:*openssl-users  *On Behalf Of 
*John Alway

*Sent:* Monday, April 11, 2022 7:06 PM
*Cc:* openssl-users@openssl.org
*Subject:* Re: RSA and DES encryption and decryption with C++ on Windows

Pauli,

Thanks for the link, but apparently that code requires having an 
account to view it.


However, I've passed the information from this thread onto the guy I'm 
working with and he's going to reevaluate what he wants to do.


Regards,

...John

<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>



Virus-free. www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> 



On Sun, Apr 10, 2022 at 5:52 PM Dr Paul Dale  wrote:

Have a look in the demos/encrypt folder:
https://github.openssl.org/openssl/openssl/tree/master/demos/encrypt

There has been an amount of effort put into updating these for 3.0
& later.  There is more to do.


Pauli

On 10/4/22 23:50, Kenneth Goldman wrote:

Anyway, I'm trying to encrypt/decrypt using RSA and DES
schemes.  I've tried some of the older code examples I could
find, but some of the functions weren't recognized by my
header files.

[kgold] You cannot encrypt long streams with RSA.  DES is
deprecated.

Can anyone help me with this?  I want to encrypt fairly long
strings.  A few hundred bytes or so.   Maybe longer.  If I can
do a continuous stream of blocks that would be great, as well.

*//*

[kgold] Post a short example that did not work.

Re: RSA and DES encryption and decryption with C++ on Windows

[Dr Paul Dale]

Have a look in the demos/encrypt folder: 
https://github.openssl.org/openssl/openssl/tree/master/demos/encrypt


There has been an amount of effort put into updating these for 3.0 & 
later.  There is more to do.



Pauli

On 10/4/22 23:50, Kenneth Goldman wrote:


Anyway, I'm trying to encrypt/decrypt using RSA and DES schemes.  I've 
tried some of the older code examples I could find, but some of the 
functions weren't recognized by my header files.


[kgold] You cannot encrypt long streams with RSA.  DES is deprecated.

Can anyone help me with this?  I want to encrypt fairly long strings.  
A few hundred bytes or so.   Maybe longer.  If I can do a continuous 
stream of blocks that would be great, as well.


*//*

[kgold] Post a short example that did not work.

Re: EVP_KDF-SSHKDF man page error?

[Dr Paul Dale]

The UTF8 type is a string and if its length is known, it doesn't need to 
be '\0' terminated.  So passing the address of a char works (it's a char 
* after all).


Thanks for the other fix.

Pauli

On 26/3/22 10:43 am, Kory Hamzeh wrote:
Thanks, Paul. I noticed the type values matched the RFC, but thought 
maybe it should be a string if that was the case.


I did find another issue:

|if (EVP_KDF_derive(kctx, out, , params) <= 0) |
|
|
The actual value of ‘outlen’ should be passed, not the address.

Kory


On Mar 25, 2022, at 4:01 PM, pa...@openssl.org wrote:

It is correct, the KDF is expecting the characters 'A' through 'F' 
here.  This is what is specified in the RFC: 
https://datatracker.ietf.org/doc/html/rfc4253#section-7.2


That line of code ought to have cast to (char *) or type defined 
simply as char, but it is essentially correct.



Pauli

On 26/3/22 5:11 am, Kory Hamzeh wrote:

Hi All,

If you look at the example SSH KDF code here:

https://www.openssl.org/docs/manmaster/man7/EVP_KDF-SSHKDF.html

Specifically, these lines:

 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
 , sizeof(type));
 The variable ‘type’ is defined as a “const char”, so an 8 bit 
integer. The compiler spits out a warning on that line. Is the 
example code correct?


 I wonder if it should be calling OSSL_PARAM_construct_int() and 
‘type’ changed to ‘int’?


Thanks,
Kory

Re: TLS KDF and SSH KDF in openssl 1.0.2 (FIPS 140-3)

[Dr Paul Dale]

Good luck, the 2.0.16 FOM is nowhere near being 140-3 ready.

The Oracle version is much closer but still not quite there: 
https://github.com/oracle/solaris-openssl-fips



Pauli

On 17/3/22 19:19, Dhananjay kumar wrote:

Hi All,
We are looking to go through FIPS 140-3 certification for one of our 
products which still runs on openssl 1.0.2(fips object module 2.0.16) 
version due to some software dependencies.
in FIPS 140-3, we are asked to explicitly implement KATs(known answer 
tests) for below algorithms since FIPS_mode_set(1) call doesn't run 
these by default.


  * *Openssl FFC DH Primitive “Z” computation KAT*

  * *Openssl TLS KDF KAT*
  * *Openssl SSH KDF KAT*

*
*
We found openssl3 provides *EVP_KDF *routines to do this but we are 
not able to find equivalent of that in openssl 1.0.2.
Any API pointers for SSH KDF, TLS KDF and DH Primitive Z computation 
in openssl 1.0.2 will be of great help.


Thanks,
Dhananjay

Re: [EXTERNAL] Re: Not able to perform FIPS self-tests

[Dr Paul Dale]

Shane Lontis suggested this:

   /Don't return 0 during the Corruption phase unless you are trying to
   deliberately make it fail./
   //
   /OSSL_PROVIDER_self_test() can be used to run the self tests on demand./

//

Dr Paul Dale


On 11/2/22 17:23, Gahlot, Ashish Kumar wrote:


Hi,

Thanks Pauli, the API worked but also I have a callback defined as 
below which is failing at corrupt phase:


int SelfTestCb(const OSSL_PARAM params[], void *arg)

{

    int ret = 0;

    const OSSL_PARAM *p = NULL;

    const char *phase = NULL;

    const char *type = NULL;

    const char *desc = NULL;

    //BIO *bio_out = BIO_new_file("FipsSelfTestFile.txt", "w");

    p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_PHASE);

    if ((p == NULL) || (arg) || (p -> data_type != 
OSSL_PARAM_UTF8_STRING))


    goto err;

    phase = (const char *)p -> data;

    p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_DESC);

    if ((p == NULL) || (p -> data_type != OSSL_PARAM_UTF8_STRING))

    goto err;

    desc = (const char *)p -> data;

    p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_TYPE);

    if ((p == NULL) || (p -> data_type != OSSL_PARAM_UTF8_STRING))

    goto err;

    type = (const char *)p ->data;

    /* Do some logging */

    if (strcmp(phase, OSSL_SELF_TEST_PHASE_START) == 0)

    syslog(LOG_NOTICE, "%s : (%s) : ", desc, type);

    if ((strcmp(phase, OSSL_SELF_TEST_PHASE_PASS) == 0)

    || (strcmp(phase, OSSL_SELF_TEST_PHASE_FAIL) ==0))

    syslog(LOG_NOTICE, "%s\n", phase);

    /* Corrupt the SHA1 self-test during the 'corrupt' phase by 
returning 0 */


    if (strcmp(phase, OSSL_SELF_TEST_PHASE_CORRUPT) == 
0){    // ß--THIS FAILS


    syslog(LOG_NOTICE, "%s %s", phase, desc);

    return 0;

    }

    ret = 1;

err:

    return ret;

}

Thanks,

Ashish

*From:* openssl-users  *On Behalf 
Of *Dr Paul Dale

*Sent:* Tuesday, February 8, 2022 1:35 PM
*To:* openssl-users@openssl.org
*Subject:* [EXTERNAL] Re: Not able to perform FIPS self-tests

Have you considered using the provided for this: 
OSSL_PROVIDER_self_test()?
https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER.html 
<https://clicktime.symantec.com/3MLQWE4xgv1bwQFXJyvrWt87GS?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FOSSL_PROVIDER.html>


Pauli

On 8/2/22 17:41, Gahlot, Ashish Kumar wrote:

Hello All,

I’m trying to execute self-tests that FIPS runs after installation
manually by calling the APIs. I’m using code from

https://github.com/openssl/openssl/blob/7cce994d3e57345ba729388b9321d9bf8b661b4f/providers/fips/self_test_kats.c

<https://clicktime.symantec.com/34e4QufezjLGGtyNv3jNidX7GS?u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fblob%2F7cce994d3e57345ba729388b9321d9bf8b661b4f%2Fproviders%2Ffips%2Fself_test_kats.c>
but I’m getting NULL when I’m trying to fetch the encryption
algorithm. Is there a way to perform self-tests that FIPS runs
after installation because I did not find any code in
fipsinstall.c where it is directly calling the APIs.

int self_test_digest(const ST_KAT_DIGEST *t, OSSL_SELF_TEST *st,
OSSL_LIB_CTX *libctx)

{

    int ok = 0;

    unsigned char out[EVP_MAX_MD_SIZE];

    unsigned int out_len = 0;

    EVP_MD_CTX *ctx = EVP_MD_CTX_new();

    EVP_MD *md = EVP_MD_fetch(libctx, t->algorithm, NULL);

    OSSL_SELF_TEST_onbegin(st, OSSL_SELF_TEST_TYPE_KAT_DIGEST,
t->desc);

    if (ctx == NULL)

    {syslog(LOG_NOTICE, "ctx NULL"); goto err;}

    if (md == NULL)

    {syslog(LOG_NOTICE, "md is NULL"); goto err;}    // 
<---  This is getting failed!

    if (!EVP_DigestInit_ex(ctx, md, NULL))

    {syslog(LOG_NOTICE, "digest failed"); goto err;}

    if (!EVP_DigestUpdate(ctx, sha1_pt, t->pt_len))

    {syslog(LOG_NOTICE, "digest update failed"); goto err;}

    if (!EVP_DigestFinal(ctx, out, _len))

    {syslog(LOG_NOTICE, "digest final failed"); goto err;}

    /* Optional corruption */

    OSSL_SELF_TEST_oncorrupt_byte(st, out);

    for (int i=0; i < (int)t->expected_len; i++)

   {syslog(LOG_NOTICE, "%x", out[i]);}

    if (out_len != t->expected_len

    || memcmp(out, sha1_digest, out_len) != 0)

    goto err;

    ok = 1;

err:

    EVP_MD_free(md);

    EVP_MD_CTX_free(ctx);

    OSSL_SELF_TEST_onend(st, ok);

    return ok;

}

static int self_test_digests(OSSL_LIB_CTX *libctx)

{

    OSSL_SELF_TEST *st = NULL;

    st = OSSL_SELF_TEST_new(SelfTestCb, NULL);

    if (st == NULL)

    syslog(LOG_NOTICE, "OSSL_SELF_TEST_new failed");

    int i, ret = 1;

    for (i = 0; i &l

Re: OpenSSL 3.0 FIPS module configuration file

[Dr Paul Dale]

There is nothing stopping cheating.

If you are going to cheat, why bother with FIPS at all?  Just claim 
you're FIPS.



Pauli

On 15/2/22 10:49, Ma Ar wrote:


Maybe a dumb question too, considering that i am admittedly just 
getting into this field, but I though maybe if I ask I might learn 
something...is there any method of assurance that the test were then 
run on the machine they are installed on?


If whatever those tests are attesting to to certify compliance can be 
falsified by copying over 1 file, what would even be to purpose of 
those tests?


Or are simply dependency checks?

Thanks for all the effort it must take in answering all these 
questions every day.


On 2/14/2022 5:31 PM, Dr Paul Dale wrote:
Yes, this has to do with the FIPS standards.  I forget which standard 
it is but the self tests are mandated to be run on each device 
independently.


The fipsinstall process runs the self tests before generating the 
configuration file.  If the self tests fail, the module doesn't 
install.  Copying the configuration file across avoids the self tests 
and therefore isn't compliant.



Pauli


On 15/2/22 02:25, Richard Dymond wrote:

Hi

Probably a dumb question, but why must the FIPS module configuration 
file for OpenSSL 3.0 be generated on every machine that it is to be 
used on (i.e. must not be copied from one machine to another)?


I just ran 'openssl fipsinstall' on two different machines with the 
same FIPS module and it produced exactly the same output each time, 
so presumably the reason has nothing to do with the config file 
being unique to the machine.


Does it have something to do with the FIPS standard itself?

Richard

Re: OpenSSL 3.0 FIPS module configuration file

[Dr Paul Dale]

Tom, thanks for looking this up.  I believe that this particular piece 
of guidance was removed in 140-3.



Pauli

On 15/2/22 10:57, Thomas Dwyer III wrote:
I believe the relevant standard is described in the Implementation 
Guidance for FIPS 140-2: 
https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf 
(see IG 9.11 beginning on page 179). I searched briefly for similar 
text in FIPS 140-3 IG but didn't see anything relevant.



Tom.III


On Mon, Feb 14, 2022 at 3:31 PM Dr Paul Dale  wrote:

Yes, this has to do with the FIPS standards.  I forget which
standard it is but the self tests are mandated to be run on each
device independently.

The fipsinstall process runs the self tests before generating the
configuration file.  If the self tests fail, the module doesn't
install.  Copying the configuration file across avoids the self
tests and therefore isn't compliant.


Pauli


On 15/2/22 02:25, Richard Dymond wrote:

Hi

Probably a dumb question, but why must the FIPS module
configuration file for OpenSSL 3.0 be generated on every machine
that it is to be used on (i.e. must not be copied from one
machine to another)?

I just ran 'openssl fipsinstall' on two different machines with
the same FIPS module and it produced exactly the same output each
time, so presumably the reason has nothing to do with the config
file being unique to the machine.

Does it have something to do with the FIPS standard itself?

Richard

Re: OpenSSL 3.0 FIPS module configuration file

[Dr Paul Dale]

Yes, this has to do with the FIPS standards.  I forget which standard it 
is but the self tests are mandated to be run on each device independently.


The fipsinstall process runs the self tests before generating the 
configuration file.  If the self tests fail, the module doesn't 
install.  Copying the configuration file across avoids the self tests 
and therefore isn't compliant.



Pauli


On 15/2/22 02:25, Richard Dymond wrote:

Hi

Probably a dumb question, but why must the FIPS module configuration 
file for OpenSSL 3.0 be generated on every machine that it is to be 
used on (i.e. must not be copied from one machine to another)?


I just ran 'openssl fipsinstall' on two different machines with the 
same FIPS module and it produced exactly the same output each time, so 
presumably the reason has nothing to do with the config file being 
unique to the machine.


Does it have something to do with the FIPS standard itself?

Richard

Re: Not able to perform FIPS self-tests

[Dr Paul Dale]

Have you considered using the provided for this: OSSL_PROVIDER_self_test()?
https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER.html

Pauli

On 8/2/22 17:41, Gahlot, Ashish Kumar wrote:


Hello All,

I’m trying to execute self-tests that FIPS runs after installation 
manually by calling the APIs. I’m using code from 
https://github.com/openssl/openssl/blob/7cce994d3e57345ba729388b9321d9bf8b661b4f/providers/fips/self_test_kats.c 
but I’m getting NULL when I’m trying to fetch the encryption 
algorithm. Is there a way to perform self-tests that FIPS runs after 
installation because I did not find any code in fipsinstall.c where it 
is directly calling the APIs.


int self_test_digest(const ST_KAT_DIGEST *t, OSSL_SELF_TEST *st, 
OSSL_LIB_CTX *libctx)


{

    int ok = 0;

    unsigned char out[EVP_MAX_MD_SIZE];

    unsigned int out_len = 0;

    EVP_MD_CTX *ctx = EVP_MD_CTX_new();

    EVP_MD *md = EVP_MD_fetch(libctx, t->algorithm, NULL);

    OSSL_SELF_TEST_onbegin(st, OSSL_SELF_TEST_TYPE_KAT_DIGEST, t->desc);

    if (ctx == NULL)

    {syslog(LOG_NOTICE, "ctx NULL"); goto err;}

    if (md == NULL)

    {syslog(LOG_NOTICE, "md is NULL"); goto err;}    //  
<---  This is getting failed!


    if (!EVP_DigestInit_ex(ctx, md, NULL))

    {syslog(LOG_NOTICE, "digest failed"); goto err;}

    if (!EVP_DigestUpdate(ctx, sha1_pt, t->pt_len))

    {syslog(LOG_NOTICE, "digest update failed"); goto err;}

    if (!EVP_DigestFinal(ctx, out, _len))

    {syslog(LOG_NOTICE, "digest final failed"); goto err;}

    /* Optional corruption */

    OSSL_SELF_TEST_oncorrupt_byte(st, out);

    for (int i=0; i < (int)t->expected_len; i++)

   {syslog(LOG_NOTICE, "%x", out[i]);}

    if (out_len != t->expected_len

    || memcmp(out, sha1_digest, out_len) != 0)

    goto err;

    ok = 1;

err:

    EVP_MD_free(md);

    EVP_MD_CTX_free(ctx);

    OSSL_SELF_TEST_onend(st, ok);

    return ok;

}

static int self_test_digests(OSSL_LIB_CTX *libctx)

{

    OSSL_SELF_TEST *st = NULL;

    st = OSSL_SELF_TEST_new(SelfTestCb, NULL);

    if (st == NULL)

    syslog(LOG_NOTICE, "OSSL_SELF_TEST_new failed");

    int i, ret = 1;

    for (i = 0; i < (int)OSSL_NELEM(st_kat_digest_tests); ++i) {

    if (!self_test_digest(_kat_digest_tests[i], st, libctx))

    ret = 0;

    }

    return ret;

}

if (!EVP_default_properties_enable_fips(libctx,1))

{

    ...

}

self_test_digests(libctx);

Thanks,

Ashish


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others 
or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.

Re: Coverity failures on github

[Dr Paul Dale]

The CIs are trying to run on your fork of the main repository and you've 
not got a Coverity token set up.

To disable the run:

1. Go to your fork of the repository
   (https://github.com/pprindeville/openssl)
2. Click onto the "Actions" tab along the top
3. Click the "Static Analysis" workflow on the bottom left.
4. Click on the ellipsis button next to the search box (...)
5. Select "Disable Workflow"



Pauli

On 4/2/22 12:44, Philip Prindeville wrote:

I'm getting daily reports about static analysis failures:

https://github.com/pprindeville/openssl/runs/5060866030?check_suite_focus=true

Which says:

Run wgethttps://scan.coverity.com/download/linux64  \
   wgethttps://scan.coverity.com/download/linux64  \
--post-data "token==openssl%2Fopenssl" \
--progress=dot:giga -O coverity_tool.tgz
   shell: /usr/bin/bash -e {0}
--2022-02-04 01:26:39--https://scan.coverity.com/download/linux64
Resolving scan.coverity.com (scan.coverity.com)... 45.60.34.99
Connecting to scan.coverity.com (scan.coverity.com)|45.60.34.99|:443... 
connected.
HTTP request sent, awaiting response... 401 Unauthorized

Username/Password Authentication Failed.
Error: Process completed with exit code 6.

Looks like there's an expired Coverity license, or the creds are incorrect?

Re: OpenSSL provider replacement for ENGINE_load_private_key

[Dr Paul Dale]

I'm not aware of a PKCS#11 provider being available at this point.


Pauli

On 13/1/22 5:02 am, Graham Leggett via openssl-users wrote:

On 13 Dec 2021, at 12:15, Tomas Mraz  wrote:


One option would be for a provider to provide provider-storemgmt
implementation to load a key from its special URI. You'd then use
OSSL_STORE from the application to load a private key from that special
URI.

Another, rather simplistic, approach would be to use the
EVP_PKEY_fromdata() function. In that case you'd have to know what the
key algorithm are you using. You'd then use EVP_PKEY_CTX_new_from_name
with query properties to include "provider=your_provider" and the
params used with EVP_PKEY_fromdata() would contain just the special id
parameter that the provider would use to identify the private key from
the device.

The specific example is for PKCS11.

Is there a PKCS11 provider available to be used?

Regards,
Graham
—

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Dr Paul Dale]

Better might be just adding a note to the parameters unlikely to fit 
into a machine integer rather than confounding things with an additional 
type which isn't really a separate type.



Pauli

"unsigned BIGNUM" instead of "unsigned integer" would be short and 
much clearer
in the description and naming of parameters unlikely to fit in a C 
int/long.

Re: EVP_PKEY_get_int_param is not getting degree from EC key

[Dr Paul Dale]

Also it's bit weird that responder *may* choose to return error if
data_size is not suitable. What else it might do? Is it valid (from
responder's point of view) to just truncate the value to that it would
fit into unsigned int (that would obviously be useless behavior, I'm
just curious if it would be compliant based on the man page).


A significant effort was put in to return an error for any integer or 
real value that couldn't be represented exactly in the returned parameter.
This was deemed better than returning a value that couldn't be exactly 
represented.



Pauli

Re: Question About OpenSSL 3.0, FIPS and Solaris Support

[Dr Paul Dale]

The "unadopted" category is not the same as "unsupported".  We'll make 
an effort but if access to a physical machine is required, we will have 
to stop.  Whoever reports a problem will like have to assist with fixing 
it.  Be that by doing builds or writing code.


The platform policy page categories are defined but the OpenSSL 
project's access to hardware.  We do not have access to Solaris boxes 
and no community member has offered to help either with support or 
provision of hardware.  This is why it is in the "unadopted" category.


Oracle, as one of the FIPS project sponsors, was entitled to having 
platforms validated.



Pauli


On 8/12/21 4:55 am, David Dillard via openssl-users wrote:


Hi,

I’m hoping someone can shed some light on something that’s confusing 
me.  In the blog post about the FIPS submission 
 
it states that one of the platforms that’s being tested is “Oracle 
Solaris 11.4 on Oracle SPARC M8-1”.  However, on the platform policy 
page  it lists a 
number of Solaris platforms, all of which are currently “unadopted”.  
How should people interpret that?  That the initial release of OpenSSL 
3.0 was supported on Solaris, but no releases after that are?  Or 
something else?


Thanks,

David

Re: Need Replacement for Deprecated function.

[Dr Paul Dale]

They are documented in provider-mac(7) 
 and 
EVP_MAC-HMAC(7) 
 respectively.


The key is the MAC key -- a string of bytes.
The digest is the name of the digest that is to be used by the MAC. 
"sha1", "sha2-256", ...


Pauli

On 4/12/21 10:55 pm, Jeremy Harris wrote:

Following along with my tidying out of now-deprecated interface uses...


The reference example in
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_tlsext_ticket_key_cb.html

uses OSSL_MAC_PARAM_KEY and OSSL_MAC_PARAM_DIGEST.

So does the code in master as of 6d770c5ba3.  But I don't see definitions
for them.  What am I missing about how these should be used?

Re: OpenSSL 1.1 on OSX

[Dr Paul Dale]

An alternative would be to statically link libssl and libcrypto.  No 
more dependencies.



Pauli

On 20/11/21 3:48 pm, Viktor Dukhovni wrote:

On Sat, Nov 20, 2021 at 01:38:39PM +1100, Grahame Grieve wrote:


I agree it's sure not a core openSSL issue. But surely lots of people
want to use openSSL in cross platform apps and openSSL is interested
in adoption issues?

Most of the users here are building applications that are not notarised,
and so work with the upstream builds.


Anyway, it looks like I now have to figure out how to maintain a
custom build of openSSL :-(

It shouldn't be too difficult to execute the build, once you've figured
out the actual requirements.  Apparently you need to make sure that
signed code has very explicit dependencies, which makes some sense, so
the libraries bundled with the application need to be built in a way
that can be verified along with the application.

My best guess is that Apple are not specifically picking on OpenSSL
here, and similar issues would arise with any other libraries you'd
want to package with your application.  Good luck.

Feel free to share your findings.  Perhaps someone will then help
you find a way to improve on them, or to add a template to the
build to support this going forward...

Re: useless search box on openssl.org

[Dr Paul Dale]

It would be nice if the search engines checked for URL validity and 
cleaned their caches from time to time.


Apart from keeping dross around from old unsupported versions, I don't 
think there is much the project can do about this unfortunately.



Pauli

On 19/11/21 7:48 am, Michael Richardson wrote:

If you go to any page on openssl.org, and using the search box, you enter,
say:
 X509_get_ext_d2i

then you go to:
  
https://www.google.com/search?sitesearch=www.openssl.org=X509_get_ext_d2i

which gives me, aas the top link:

X509V3_get_d2i - OpenSSLhttps://www.openssl.org › man3 › X509_get_ext_d2i
X509V3_get_ext_d2i() looks for an extension with OID nid in the extensions x
and, if found, decodes it. If idx is NULL then only one occurrence of an
extension ...

which is a link to:
   https://www.openssl.org/docs/man1.1.0/man3/X509_get_ext_d2i.html

which is Page Not Found.  I guess because man1.1.1 is now current.
With no forwarder.

Re: OpenSSL 3: FIPS DRBG Tests

[Dr Paul Dale]

On 12/11/21 4:02 am, Kory Hamzeh wrote:

I am writing the FIPS DRBG AVS per NIST SP800-90A. I have some questions.

1. Is the TEST-RAND ok for nist test? I am planning to basically follow the 
steps in test/acvp_test.c:drbg_test(), but the data is read in from a file 
rather than an in memory structure.
This is one of the things it is intended for.  You might consider 
writing a BIO-RAND that reads its input from a BIO or one that reads 
from a file.  TEST-RAND is in memory only but the amount of data 
shouldn't be too large to handle.




2. Some of the test vectors provide you with a 2nd entropy value to use for the 
2nd call to generate. Can I call EVP_RAND_set_prams() with a  
OSSL_RAND_PARAM_TEST_ENTROPY before the 2nd call to generate?

Yes you can.

You ought to to look at the function rand_test_run() in test/evp_test.c 
(as well as the code before and after).  This is processing slightly 
munged CAVs data and does everything you should need.




3. And finally, our existing test, based on openssl-fips-2.0.5 called 
FIPS_drbg_new(). That function allows you to pass an EC curve NID in the upper 
16 bits of the drbg type. Not sure how to do this in OpenSSL 3, however, I see 
no mention of EC curves in:

https://csrc.nist.gov/csrc/media/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgvs.pdf

So it may be a moot issue.
It's moot.  None of the approved DRBGs use EC anymore.  There was a bit 
of controversy a number of years ago about the Dual-EC DRBG: it's almost 
certainly back-doored by the US government.



Pauli

Re: Is it possible to use a global lock in the OpenSSL engine on each mod_ssl call?

[Dr Paul Dale]

OpenSSL doesn't have a global lock.
You could implement a single lock in the engine.  Grab it immediately on 
entry and release just before exit.



Pauli

On 11/11/21 8:24 am, Shariful Alam wrote:

Hello,
I understand this is a weird question. I have an OpenSSL engine only 
for RSA. And I have apache installed that uses this OpenSSL engine for 
the HTTPS connection.


I was wondering if it is possible to use a global lock with the 
OpenSSL on mod_ssl call? So that, only one mod_ssl thread cal call the 
engine at a time?


Thanks,
Shariful

Re: OpenSSL-3.+ how to configure [random]?

[Dr Paul Dale]

I'm pretty sure the underlying problem is that there is a call to 
RAND_set_rand_method() or RAND_set_rand_engine() occurring (likely the 
latter).


These completely replace the built in RNG infrastructure with the 
RAND_METHOD/engine.  If the engine then fails to produce output for any 
reason, the observed results will present.


Adding the RDRAND engine again replaces the RAND_METHOD and things begin 
working.



I've no idea why the PKCS#11 engine has stopped working with 3.0. It 
wasn't meant to.



Pauli

On 11/11/21 1:36 am, Blumenthal, Uri - 0553 - MITLL wrote:

Yes, it's related to https://github.com/openssl/openssl/issues/16996, and yes - 
the same solution worked.

There's something wrong with how PKCS#11 engine deals with (or presents itself 
as) rand provider.
In any case, removing PKCS#11 engine from the [engines] section alleviated this 
problem.

Thanks!

P.S. I configured rand seed sources the standard way: 
"--with-rand-seed=rdcpu,os", as I think everybody does.

Re: OpenSSL-3.+ how to configure [random]?

[Dr Paul Dale]

There is documentation: https://www.openssl.org/docs/man3.0/man5/config.html

I don't think the rdrand engine takes any extras.


Pauli

On 10/11/21 1:38 pm, Blumenthal, Uri - 0553 - MITLL wrote:

On 11/9/21, 22:23, "Dr Paul Dale"  wrote:


Currently I've no idea and can't reproduce locally :(

Maybe you'd know how to force the "-engine rdrand" path through "openssl.cnf"?


A rogue configuration file could cause the DRBGs/seeds to fail.  Do you
have seed=rdrand line in the random section?  That will cause the
seeding source to fail to load at all.

No, I don't - and providing empty config causes the same result:

$ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
$ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
61f1666d
$


 Pauli

 On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
 > Thank you!
 >
 > I'm trying to:
 >
 > a. understand why something like "openssl-3 rand -hex 4" does not work (returns 
empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives me my random 
bytes - here's an illustration
 >
 > $ openssl3 version
 > OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
 > $ openssl3 info -seeds
 > rdrand ( rdseed rdrand ) os-specific
 > $ openssl3 rand -hex 4
 > $ openssl3 rand -engine rdrand -hex 4
 > Engine "rdrand" set.
 > d9b8f268
 >
 > and
 >
 > b. somehow force RDRAND engine to be loaded and initialized by default, so I don't have to 
include "-engine rdrand" in every invocation, especially since I often need to specify other 
engines (like "pkcs11").
 >
 > Here's my config, in case you spot something wrong with it (and yes, it includes 
"rdcpu"):
 >
 > ./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc 
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace enable-trace 
threads enable-buildtest-c++
 >
 > Thanks
 > --
 > Regards,
 > Uri
 >
 > There are two ways to design a system. One is to make is so simple there 
are obviously no deficiencies.
 > The other is to make it so complex there are no obvious deficiencies.
 >  
 -  C. A. R. Hoare
 >
 >
 > On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale" 
 wrote:
 >
 >  Currently there is exactly one seed source that is usable in OpenSSL
 >  3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The 
reason the
 >  seed source can be set is to allow you to use a third party provider
 >  than includes one.
 >
 >  If you want to force RDRAND as the only seeding source, this needs 
to be
 >  done at configuration time with the --with-rand-seed configuration
 >  option.  Note that this will enable RDSEED in preference to RDRAND 
but
 >  will use RDRAND if RDSEED isn't available.
 >
 >  I assume that you meant openssl info -seeds not openssl list -seeds.
 >  This lists the seed sources that were configured at build time.
 >
 >
 >  There is no relationship between the RDRAND engine and the seed
 >  sources.  Well, they both use the same machine instruction to get 
the
 >  seed material but it's called from completely different places.
 >
 >
 >  Yes, the man pages could be more informative and user friendly :(
 >
 >
 >  Pauli
 >
 >  On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
 >  > "man config" for OpenSSL-3.0 and newer says that there can be "[random]" 
section in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed 
*properties*.
 >  >
 >  > Unfortunately, it did not bother to even list the 
possible/allowed values, let alone explain what they'd mean:
 >  >
 >  > Random Configuration
 >  > The name random in the initialization section names the 
section containing the random number
 >  > generater settings.
 >  >
 >  > Within the random section, the following names have 
meaning:
 >  >
 >  > random
 >  > This is used to specify the random bit generator.  
For example:
 >  >
 >  >  [random]
 

Re: OpenSSL-3.+ how to configure [random]?

[Dr Paul Dale]

Currently I've no idea and can't reproduce locally :(

A rogue configuration file could cause the DRBGs/seeds to fail.  Do you 
have seed=rdrand line in the random section?  That will cause the 
seeding source to fail to load at all.



Pauli

On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:

Thank you!

I'm trying to:

a. understand why something like "openssl-3 rand -hex 4" does not work (returns empty 
string), but "openssl-3 rand -engine rdrand -hex 4" works fine, and gives me my random 
bytes - here's an illustration

$ openssl3 version
OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
$ openssl3 info -seeds
rdrand ( rdseed rdrand ) os-specific
$ openssl3 rand -hex 4
$ openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
d9b8f268

and

b. somehow force RDRAND engine to be loaded and initialized by default, so I don't have to include 
"-engine rdrand" in every invocation, especially since I often need to specify other 
engines (like "pkcs11").

Here's my config, in case you spot something wrong with it (and yes, it includes 
"rdcpu"):

./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc 
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace 
enable-trace threads enable-buildtest-c++

Thanks
--
Regards,
Uri
  
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

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

  -  C. A. R. Hoare
  


On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale" 
 wrote:

 Currently there is exactly one seed source that is usable in OpenSSL
 3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The reason the
 seed source can be set is to allow you to use a third party provider
 than includes one.

 If you want to force RDRAND as the only seeding source, this needs to be
 done at configuration time with the --with-rand-seed configuration
 option.  Note that this will enable RDSEED in preference to RDRAND but
 will use RDRAND if RDSEED isn't available.

 I assume that you meant openssl info -seeds not openssl list -seeds.
 This lists the seed sources that were configured at build time.


 There is no relationship between the RDRAND engine and the seed
 sources.  Well, they both use the same machine instruction to get the
 seed material but it's called from completely different places.


 Yes, the man pages could be more informative and user friendly :(


 Pauli

 On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
 > "man config" for OpenSSL-3.0 and newer says that there can be "[random]" section 
in "openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *properties*.
 >
 > Unfortunately, it did not bother to even list the possible/allowed 
values, let alone explain what they'd mean:
 >
 > Random Configuration
 > The name random in the initialization section names the section 
containing the random number
 > generater settings.
 >
 > Within the random section, the following names have meaning:
 >
 > random
 > This is used to specify the random bit generator.  For 
example:
 >
 >  [random]
 >  random = CTR-DRBG
 >
 > The available random bit generators are:
 >
 > CTR-DRBG
 > HASH-DRBG
 > HMAC-DRBG
 > .  .  .  .  .
 > properties
 > This sets the property query used when fetching the random 
bit generator and any
 > underlying algorithms.
 >
 > seed
 > This sets the randomness source that should be used.  By 
default SEED-SRC will be used
 > outside of the FIPS provider.  The FIPS provider uses call 
backs to access the same
 > randomness sources from outside the validated boundary.
 >
 > seed_properties
 > This sets the property query used when fetching the 
randomness source.
 >
 > I want to configure this [random] to use CTR-DRBG, using RDRAND as "seed". Based on "openssl list 
-seeds", I guess "seed = rdrand" should be OK. What properties can I set, if any? How does this 
"[random]" relate to the RDRAND *engine* (see below)?
 >
 > $ openssl3 engine rdrand -t
 > (rdrand) Intel RDRAND engine
 >   [ available ]
 

Re: OpenSSL-3.+ how to configure [random]?

[Dr Paul Dale]

Currently there is exactly one seed source that is usable in OpenSSL 
3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The reason the 
seed source can be set is to allow you to use a third party provider 
than includes one.


If you want to force RDRAND as the only seeding source, this needs to be 
done at configuration time with the --with-rand-seed configuration 
option.  Note that this will enable RDSEED in preference to RDRAND but 
will use RDRAND if RDSEED isn't available.


I assume that you meant openssl info -seeds not openssl list -seeds.  
This lists the seed sources that were configured at build time.



There is no relationship between the RDRAND engine and the seed 
sources.  Well, they both use the same machine instruction to get the 
seed material but it's called from completely different places.



Yes, the man pages could be more informative and user friendly :(


Pauli

On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:

"man config" for OpenSSL-3.0 and newer says that there can be "[random]" section in 
"openssl.cnf", where I can specify type of RNG, other things, and *seed*, and seed *properties*.

Unfortunately, it did not bother to even list the possible/allowed values, let 
alone explain what they'd mean:

Random Configuration
The name random in the initialization section names the section 
containing the random number
generater settings.

Within the random section, the following names have meaning:

random
This is used to specify the random bit generator.  For example:

 [random]
 random = CTR-DRBG

The available random bit generators are:

CTR-DRBG
HASH-DRBG
HMAC-DRBG
.  .  .  .  .
properties
This sets the property query used when fetching the random bit 
generator and any
underlying algorithms.

seed
This sets the randomness source that should be used.  By default 
SEED-SRC will be used
outside of the FIPS provider.  The FIPS provider uses call backs to 
access the same
randomness sources from outside the validated boundary.

seed_properties
This sets the property query used when fetching the randomness 
source.

I want to configure this [random] to use CTR-DRBG, using RDRAND as "seed". Based on "openssl list 
-seeds", I guess "seed = rdrand" should be OK. What properties can I set, if any? How does this 
"[random]" relate to the RDRAND *engine* (see below)?

$ openssl3 engine rdrand -t
(rdrand) Intel RDRAND engine
  [ available ]


Thanks!
--
Regards,
Uri Blumenthal  Voice: (781) 981-1638
Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA  02420-9108
  
Web: https://www.ll.mit.edu/biographies/uri-blumenthal

Root CA: https://www.ll.mit.edu/llrca2.pem
  
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

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

  -  C. A. R. Hoare
  

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

It was meant for the second method only.  The first method is using 
different library contexts to distinguish FIPS algorithms.  Using the 
properties in addition is harmless and might prevent a future mistake 
that breaks compliance.


Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your 
initial response, there is something I'm not clear on.


The second method you explained (which I don't plan to use) starting 
with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), 
and then discussed calling the following API for FIPS:

    EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for 
the 2nd method, or did that API call apply to both the first and 
second methods you explained? From reading the doc for that call, it 
seems like I should be doing it if I use the first method as well.


Regards,

Jason


*From:* openssl-users  on behalf of 
Dr Paul Dale 

*Sent:* Sunday, October 24, 2021 11:12 PM
*To:* openssl-users@openssl.org 
*Subject:* Re: OpenSSL 3.0 FIPS questions
The configuration shouldn't have much impact.  You will need a fips 
section specifying where the integrity check data are.  You shouldn't 
need base or default sections.



Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and 
seems to accomplish what I want programmatically, limiting it to my 
application. I guess the only question I have is what about the 
config files? Should they remain as they were installed, or do I need 
to provide sections for fips, base, default, etc?


Regards,

Jason



*From:* openssl-users  
<mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale 
 <mailto:pa...@openssl.org>

*Sent:* Sunday, October 24, 2021 12:28 AM
*To:* openssl-users@openssl.org <mailto:openssl-users@openssl.org> 
 <mailto:openssl-users@openssl.org>

*Subject:* Re: OpenSSL 3.0 FIPS questions
Oops, the second time this occurs "defp = 
OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = 
OSSL_PROVIDER_load(NULL, "default");"



Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

The configuration shouldn't have much impact.  You will need a fips 
section specifying where the integrity check data are.  You shouldn't 
need base or default sections.



Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and 
seems to accomplish what I want programmatically, limiting it to my 
application. I guess the only question I have is what about the config 
files? Should they remain as they were installed, or do I need to 
provide sections for fips, base, default, etc?


Regards,

Jason



*From:* openssl-users  on behalf of 
Dr Paul Dale 

*Sent:* Sunday, October 24, 2021 12:28 AM
*To:* openssl-users@openssl.org 
*Subject:* Re: OpenSSL 3.0 FIPS questions
Oops, the second time this occurs "defp = 
OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = 
OSSL_PROVIDER_load(NULL, "default");"



Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

Oops, the second time this occurs "defp = 
OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = 
OSSL_PROVIDER_load(NULL, "default");"



Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

There are several approaches you could take.  With two library contexts:

   fips_libctx = OSSL_LIB_CTX_new();
   non_fips_libctx = OSSL_LIB_CTX_new();

   fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
   basep = OSSL_PROVIDER_load(fips_libctx,"base");  /* can't load keys
   without this */
   defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
   nullp = OSSL_PROVIDER_load(NULL, "null");       /* Disallow falling
   back to the default library context */


Then use either fips_libctx or non_fips_libctx for operations.


Alternatively, it can be done in one library context (the default here), 
although there is some risk of using non-FIPS crypto in a FIPS context:


   fipsp = OSSL_PROVIDER_load(NULL, "fips");
   defp = OSSL_PROVIDER_load(non_fips_libctx, "default");


For FIPS, make sure that "fips=yes" is included as a property query.  
The easiest way is to do this globally:


   EVP_set_default_properties(NULL, “fips=yes”);

For non-FIPS, just don't do anything.


Personally, I'd do the former two library contexts based approach and 
not worry about the properties.



Pauli

On 24/10/21 2:58 am, Jason Schultz wrote:


Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm 
just trying to get my application updates done in advance.



I’m porting an application from OpenSSL 1.1.1, which was originally 
written for OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to 
incorporate FIPS usage. My Linux application basically is told if its 
user wants to use FIPS or not. We don’t use the cryptographic APIs 
(EVP_*), we just need to create an SSL_CTX, and SSL objects created 
with SSL_new() based on this SSL_CTX, which will then call SSL_read(), 
SSL_write(), etc. The application won’t “fetch” any algorithms. So my 
focus can been on Section 7.7 of the Wiki:


https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS

Based on if FIPS is on or off, I will use the replacement for 
SSL_CTX_new() and call SSL_CTX_new_ex() either something like this:


ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());

or this:

ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method());

Depending on if the users does not want FIPS, or wants FIPS, 
respectively.


Based on that and what Section 7.7 tells me, I know I need:

 1. A non-default library context with the FIPS provider loaded
(called fips_libctx), and
 2. A non-default library context with the default provider loaded
(called non_fips_libctx)

I know that I don’t want all applications using OpenSSL to use the 
FIPS module by default, so I’m just trying to configure mine 
correctly, using the APIs (and possibly config files). I also 
obviously don’t want to make my application use the FIPS module only.


Given all of the above I’m confused on how to set up #1 and #2. It 
seems like I need to use a combination of configuration files and 
programmatically calling APIs in my application. In the Wiki and the 
fips_module man page there is a section called “Programmatically 
loading the FIPS module (nondefault library context)”. I’m pretty sure 
this is what I want. The code example says it “assumes the existence 
of a config file called openssl-fips.cnf that automatically loads and 
configures the FIPS and base providers.”


The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are 
in /usr/local/ssl/: openssl.cnf and fipsmodule.cnf.


I guess the first thing is I’m confused on if the “openssl-fips.cnf” 
file referred to in the example is in addition to the two files above, 
or a replacement for one of them, and also what the contents of it 
need to be.


I had already made changes to the openssl.cnf file for FIPS (described 
in earlier sections of the Wiki):


# For FIPS

# Optionally include a file that is generated by the OpenSSL fipsinstall

# application. This file contains configuration data required by the 
OpenSSL


# fips provider. It contains a named section e.g. [fips_sect] which is

# referenced from the [provider_sect] below.

# Refer to the OpenSSL security policy for more information.

.include */usr/local/ssl/fipsmodule.cnfß***uncommented

[openssl_init]

providers = provider_sect

# List of providers to load

[provider_sect]

default = default_sect

# The fips section name should match the section name inside the

# included fipsmodule.cnf.

fips = fips_sectßuncommented

# If no providers are activated explicitly, the default one is 
activated implicitly.


# See man 7 OSSL_PROVIDER-default for more details.

#

# If you add a section explicitly activating any other provider(s), 
you most


# probably need to explicitly activate the default provider, otherwise it

# becomes unavailable in openssl.As a consequence applications 
depending on


# OpenSSL may not work correctly which could lead to significant system

# problems including inability to remotely access the system.

[default_sect]

activate = 1ßuncommented

I did this to make sure the FIPS provider was available and make 

Re: OpenSSL 3.0.0 FIPS compatible ECDH-KAS

[Dr Paul Dale]

Kory,

The situation is more complicated but your solution below is the one I'd 
have suggested.


SP800-90B says bad things about /dev/random but this is modified by IG 
7.14 indicates that it is okay to use /dev/random. Then IG 7.19 says 
that it isn't.  The current FIPS 140-2 validation is sidestepping the 
ongoing changes to the standards and mandates by placing the entropy 
collection outside the FIPS boundary.  This will incur a caveat but it 
is the best we could hope for given the variety of platforms being 
validated and the rate of change of the commandments.


Pauli


On 8/10/21 6:23 am, Kory Hamzeh wrote:

Hi Pauli,

I had some success by doing this:


static const OSSL_ALGORITHM sc4k_rands[] = {
 { "SC4K-SEED-SRC", "fips=yes", sc4k_seed_src_functions },
 { NULL, NULL, NULL }
};

and passing “fips=yes” when I set the seed source.

I am still curious to know is the FIPS module uses  
providers/implementations/rands/seed_src.c to seed the RNG. My understanding is 
that /dev/random is not secure enough per NIST SP-800-90B.

Sorry I picked the wrong message thread for these questions. This is about my 
custom entropy source that you helped ne with.

Thanks,
Kory


.

On Oct 7, 2021, at 11:19 AM, Kory Hamzeh  wrote:

Hi Pauli,

Running into a strange problem. My custom seed source works fine, but if I call:
   EVP_set_default_properties(NULL, "fips=yes");

Then my seed source is not used. Does FIPS have its own seed source? The whole 
purpose of this exercise was to create a NIST SP-800-90B compliant entropy 
source for FIPS.

Thanks,
Kory



On Sep 22, 2021, at 3:51 PM, Dr Paul Dale  wrote:

If you are only using functions that are deprecated, you'll get away without 
for the moment.

Pauli

On 23/9/21 8:45 am, Kory Hamzeh wrote:

Hi Pauli,

Thanks for the reply. Yes, I have loaded the base and fips providers.

But just to clarify, I still need to rewrite to low-level code to use the EVP 
code, correct?

Thanks,
Kory



On Sep 22, 2021, at 3:29 PM, Dr Paul Dale  wrote:

Adding that should be enough to force only FIPS validated algorithms are used.

Just doing that isn't enough, there is more you are going to need to do.  E.g. 
you will need to load the FIPS and base providers either via config or 
explicitly.

It's possible to set the default properties via config too.


Everything is documented and I'd recommend starting with the migration guide 
manual page and working from there.

In my opinion, the 1.0 -> 1.1 transition is the more onerous part.


Pauli

On 23/9/21 3:44 am, Kory Hamzeh wrote:

I have an OpenSSL app which performs ECDH-KAS using openssl-1.0.1g + 
openssl-fips-2.0.5. It needs to be FIPS compatible. The app was written using 
the low level ECDH functions similar to what is documented here:

https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman#Using_the_Low_Level_APIs

According to the OpenSSL 3.0.0 Wiki, I MUST rewrite my code to use the high 
level EVP functions if I want FIPS compatibility. If so, I was going to follow 
the EVP example at the top of the same URL above.

However, I can use some help. Using the EVP example on that page, when and 
which methods do I need to fetch? If I just add this at the top:

   EVP_set_default_properties(NULL, "fips=yes”);

will that be enough?

Thanks,
Kory

Re: fips 140-2 module conditions and compilation target app

[Dr Paul Dale]

I think you've got the fist of the restriction.  You cannot make any 
changes to the source code, build files or the commands you use to build 
the FOM.  None are acceptable if you want a FIPS validate outcome.  I.e. 
you will lose the FIPS 140-2 validation state if you change anything.



Pauli


On 5/10/21 5:42 am, Artem Goussev wrote:

 hi,
I develop my application and I need to use OpenSSL 1.0.2 with the 
OpenSSL FIPS Object Module 2.0. I know that OpenSSL 3.0 was 
released, but unfortunately I must use OpenSSL 1.0.2.


I have read   OpenSSL FIPS Object Module 2.0 documentation and I have 
one misunderstanding.


*"note that as a condition of the FIPS 140-2 validation no other user 
specified configuration options may be specified."*

*
*
Does it mean that I can't make any changes in the build configuration 
files? For example, can I change some compilation flags(CFLAGS) or 
change the list of linked libraries in makefile or others? If I do it 
will I lose some FIPS-140-2 validation or as a result, will I get an 
incorrect FIPS 140-2 library or will I lose some FIPS 140-2 compliance 
? Can you explain it to me please ?


i already know that i can't change any configuration settings in make 
files.


it means that command
      ms\do_fips
build fips module with CFLAG /MD


and I can't change it, corect? i can't build a fips module with option 
/MT, correct?



So it means I can use openssl only in /MD mode, correct? so my target 
windows console app\dll can be only in /MD mode, correct?


can you help me to understand plz?

thanks.

Re: tpm2-openssl, a TPM 2.0 provider for OpenSSL 3.0 released

[Dr Paul Dale]

Great work!


Pauli

On 30/9/21 4:13 am, Petr Gotthard wrote:

Hello,

I just released a first version of the tpm2-openssl provider.

TPM is a hardware crypto-processor, which can generate, store, and use 
cryptographic keys. The tpm2-openssl is a provider for integration of TPM 2.0 
to OpenSSL 3.0, which makes (some) functions of a TPM 2.0 chip accessible via 
the standard OpenSSL API (EVP) and command-line tools.

See the README for more details: https://github.com/tpm2-software/tpm2-openssl

I'd like to express my gratitude to the OpenSSL team, who helped me to find the 
right approach, fixed bugs and accepted pull requests that made this work 
possible. Thank you very much!
  
Kind Regards,

Petr
  

Re: RSA provider use example

[Dr Paul Dale]

On 24/9/21 9:15 pm, Angus Robertson - Magenta Systems Ltd wrote:

I've been wondering if this is more efficient than getting the
parameters one at a time using multiple EVP_PKEY_get_xx_param which
also calls EVP_PKEY_get_params.


I'd be surprised if there was a lot of difference.
If I had to give a guess (and it is a guess), I'd go for ever so 
slightly more efficient your way.



Pauli

Re: RSA provider use example

[Dr Paul Dale]

What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c
3.0 doesn't use the RSA structure in the non-deprecated public API.

You probably want the EVP_PKEY_fromdata call.


Pauli


On 24/9/21 8:55 pm, Antonio Santagiuliana wrote:

Hello
Is there any app or command in the current Openssl master repository 
that initialises and uses the new RSA provider?
I would like to see how the RSA* context parameter is filled in and 
used, but I can't find an example using the RSA provider.



Thank you

Re: OpenSSL 3.0.0 FIPS compatible ECDH-KAS

[Dr Paul Dale]

Adding that should be enough to force only FIPS validated algorithms are 
used.


Just doing that isn't enough, there is more you are going to need to 
do.  E.g. you will need to load the FIPS and base providers either via 
config or explicitly.


It's possible to set the default properties via config too.


Everything is documented and I'd recommend starting with the migration 
guide manual page and working from there.


In my opinion, the 1.0 -> 1.1 transition is the more onerous part.


Pauli

On 23/9/21 3:44 am, Kory Hamzeh wrote:

I have an OpenSSL app which performs ECDH-KAS using openssl-1.0.1g + 
openssl-fips-2.0.5. It needs to be FIPS compatible. The app was written using 
the low level ECDH functions similar to what is documented here:

https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman#Using_the_Low_Level_APIs

According to the OpenSSL 3.0.0 Wiki, I MUST rewrite my code to use the high 
level EVP functions if I want FIPS compatibility. If so, I was going to follow 
the EVP example at the top of the same URL above.

However, I can use some help. Using the EVP example on that page, when and 
which methods do I need to fetch? If I just add this at the top:

   EVP_set_default_properties(NULL, "fips=yes”);

will that be enough?

Thanks,
Kory

Re: Openssl aes-256 ctr drbg

[Dr Paul Dale]

The number you asked for typically.

Pauli

On 21/9/21 4:49 pm, Nagarjun J wrote:

Hi,
What is the Number of Bytes Returned by aes-256 ctr drbg ?

Thanks,
Nagarjun

Re: openssl 3.0.0 equivalent to RSA_get0_key

[Dr Paul Dale]

No.

The deprecated functions are not going away any time soon but there is 
no direct replacement.



Pauli

On 21/9/21 6:46 am, Ken Goldman wrote:

... and RSA_get0_factors.

I know about EVP_PKEY_get_bn_param().  However, that allocates new 
bignums.  Therefore, the caller has to say, if >3.0.0, free them, else 
don't.


The deprecated get0 functions just returned pointers that did not have 
to be separately freed.


Is there a call to pass in an EVP_PKEY and get references to existing 
n,e,p, not allocated bignums?

Re: Reducing the footprint of a simple application

[Dr Paul Dale]

Jakob,

That's reasonable, although I wouldn't use the word "low" to describe it.
I did try to include 10.1.2 from NIST's SP 800-90C but it didn't make it.

There is nothing preventing the use of the existing DRBGs with longer 
digests which Could increase number of bits.


Pauli

On 15/9/21 11:34 pm, Jakob Bohm via openssl-users wrote:

On 2021-09-14 12:14, Dr Paul Dale wrote:



> ...low security RNGs and other antifeatures.

Huh  Where?  Why plural?

The only **one** I'm aware of is the one I added to stochastically 
flush the property cache where it doesn't need to be 
cryptographically secure.


Some applications need more than 256 independent random bits to 
satisfy their
security design.  Some of the newer RNGs in OpenSSL presume otherwise 
in their

government design.


Enjoy

Jakob

Re: Openssl 3.0.0. EVP_PKEY RSA is NULL

[Dr Paul Dale]

On 15/9/21 9:19 am, Ken Goldman wrote:

irc = EVP_PKEY_fromdata_init(ctx);
irc = EVP_PKEY_fromdata(ctx, (EVP_PKEY **)rsa_pub_key, /* freed by 
caller */

    EVP_PKEY_PUBLIC_KEY, params);


Do you mean :
    irc = EVP_PKEY_fromdata(ctx, _pub_key, EVP_PKEY_PUBLIC_KEY, 
params);

here?

The cast looks wrong.


Pauli

Re: Reducing the footprint of a simple application

[Dr Paul Dale]

> ...low security RNGs and other antifeatures.

Huh  Where?  Why plural?

The only **one** I'm aware of is the one I added to stochastically flush 
the property cache where it doesn't need to be cryptographically secure.



Pauli

Re: OpenSSL 3.0.0 custom entropy source

[Dr Paul Dale]

Try working from providers/implementations/rands/seed_src.c  You'll need 
to reimplement seed_src_generate() to use your RNG.


To use your custom seed source, you can either use the OpenSSL 
configuration file to set a "random" section that includes a "seed" 
setting or you can call RAND_set_seed_source_type() early in your 
startup sequence.



Pauli

On 14/9/21 8:19 am, Kory Hamzeh wrote:

Hi,

We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. Yes, I know, 
big jump. We have our own entropy source we use to seed the OpenSSL DRBG. This 
is a basic code snippet of how we set it up:

 DRBG_CTX *dctx = FIPS_get_default_drbg();
 FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF);
 FIPS_drbg_set_callbacks(dctx,
rand_get_entropy,
   rand_free_entropy,
   0,
   rand_get_entropy,
   rand_free_entropy);


Error checking has been removed in the example for the sake of brevity.

I am trying to figure out  how to implement this with OpenSSL 3. From what I 
have read in the docs, I need to create a rand provider. But I still feel like 
I don’t understand how it all fit together. I did look at fuzz_rand.c and 
fake_rand.c, and if I understood everything correctly, neither of them use an 
external entropy/seed source.

Are there better examples of what I am looking for?

Thanks,
Kory

Re: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu )

[Dr Paul Dale]

What Ben suggests is a great start.

Note that none of the core developers have Solaris access, so that 
debugging could be problematic.



Pauli


On 12/9/21 1:39 pm, Benjamin Kaduk via openssl-users wrote:

On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote:

This is slightly better than the beta release :

Test Summary Report
---
03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1)
   Failed test:  1
   Non-zero exit status: 1


What can I dig into here to get more information and perhaps we solve
these two little tests fails?

`make V=1 TESTS="test_internal_modes test_ige" test`

-Ben

Re: EVP_MAC_init - specify the hash algorithm

[Dr Paul Dale]

My mistake, it's EVP_MAC_fetch not EVP_MAC_new.

The names are all case insensitive and are documented in the man7 pages: 
https://www.openssl.org/docs/man3.0/man7/EVP_MAC-HMAC.html and 
https://www.openssl.org/docs/man3.0/man7/EVP_MD-SHA2.html.


The HMAC parameter names and types are also there: 
https://www.openssl.org/docs/man3.0/man7/EVP_MAC-HMAC.html



Pauli


On 10/9/21 9:07 am, Ken Goldman wrote:

Where does one get the parameter values?

E.g., where would I see the value strings for the EVP_MAC_new algorithm
and the digest parameter values.

I can guess HMAC and SHA256, but are they documented?

Case sensitive?  Which is preferred?

You use EVP_MAC_new, which is undocumented.  The doc sample
uses EVP_MAC_fetch.  Which is preferred?

On 7/13/2021 7:06 PM, Dr Paul Dale wrote:


Your code should look more like:

    OSSL_PARAMS params[2];
    EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL);
    EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac);
    EVP_MAC_free(mac); /* Now or later is all good and depends on the 
app reusing it or not */


    params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 
0);

    params[1] = OSSL_PARAMS_construct_end();

    EVP_MAC_init(mac_ctx, key, key_len, params);
    EVP_MAC_update(mac_ctx, data1, data1_len);
    EVP_MAC_update(mac_ctx, data2, data2_len);
    EVP_MAC_update(mac_ctx, data3, data3_len);
    EVP_MAC_final(mac_ctx, out, _size, out_len);
    EVP_MAC_CTX_free(mac_ctx);

Re: Congratulations! Missing 3.0.0 tag?

[Dr Paul Dale]

With the change to (almost) semantic versioning, we also decided to make 
the tags easier to type.


Pauli


On 9/9/21 9:03 am, Steffen Nurpmeso wrote:

Benjamin Kaduk wrote in
  <2021090848.gx19...@akamai.com>:
  |On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote:
  |>
  |> P.S.: maybe at least release commits and tags could be signed?
  |> And/or HTTPS access to the repository ... but then i get the gut
  |> feeling that the answer to this will be "use github" or something.
  |
  |tag openssl-3.0.0
  |Tagger: Richard Levitte 
  |Date:   Tue Sep 7 13:46:40 2021 +0200
  |
  |OpenSSL 3.0.0 release tag
  |-BEGIN PGP SIGNATURE-
  |
  |iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF
  |O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w==
  |=pGf9
  |-END PGP SIGNATURE-
  |
  |looks signed to me.

That is really interesting now.
If i use "git show openssl-3.0.0" i see this myself.

   tag openssl-3.0.0
   Tagger: Richard Levitte 
   TaggerDate: 2021-09-07 13:46:40 +0200

   OpenSSL 3.0.0 release tag
   -BEGIN PGP SIGNATURE-

   iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF
   O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w==
   =pGf9
   -END PGP SIGNATURE-

   commit 89cd17a031 (tag: refs/tags/openssl-3.0.0)
   ...

But if i use

   #?0|kent:tls-openssl.git$ alias gl1
   alias gl1='git slpn -1'
   #?0|kent:tls-openssl.git$ git alias|grep slpn
   alias.slpn log --show-signature --patch --find-renames --stat 
--no-abbrev-commit
   #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0
   commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: 
refs/tags/openssl-3.0.0)
   ...

i do not.  Hm, maybe i need to relearn git again, looking around
i see a couple of projects for which this is true (Linux,
wireguard-tools), for others it is not (my own project, nghttp2).
Eg "alias.slo log --show-signature --oneline --graph":

   #?141|kent:nail.git$ git slo -1 master
   Reading passphrase from file descriptor 4
   * 69be61071c (...) gpg: Signature made Wed 01 Sep 2021 01:19:46 PM CEST
   | gpg:using RSA key DF082F6AEEC8C2FF
   | gpg: Good signature from "Steffen Nurpmeso "
   | gpg: WARNING: This key is not certified with a trusted signature!
   | gpg:  There is no indication that the signature belongs to the 
owner.
   | Primary key fingerprint: EE19 E1C1 F2F7 054F 8D39  54D8 3089 64B5 1883 A0DD
   |  Subkey fingerprint: 8A2A 4D60 9FDC 539C 75F5  5B95 DF08 2F6A EEC8 C2FF
   | Clear an installed alarm(2) in fork(2)ed childs (Stephen Isard)

   #?0|kent:nghttp2.git$ git slo -1 fcc20334da
   Reading passphrase from file descriptor 4
   *   fcc20334da gpg: Signature made Sat 04 Sep 2021 10:26:47 AM CEST
   |\  gpg:using RSA key 4AEE18F83AFDEB23
   | | gpg: Can't check signature: public key not found
   | | Merge pull request #1613 from mkauf/check_pseudo_header_chars

   #?0|kent:wireguard-tools.git$ git slo -1 v1.0.20210424
   * ecb1ea29d7 (tag: refs/tags/v1.0.20210424) version: bump

   #?128|kent:linux.git$ git slo -1 v5.10.62
   * f6dd002450 (tag: refs/tags/v5.10.62, refs/remotes/origin/linux-5.10.y) 
Linux 5.10.62

Ooops, i am totally off again.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Help Needed for deprecated functions and macros like "CRYPTO_num_locks()" , "CRYPTO_LOCK" ......etc

[Dr Paul Dale]

Locking in OpenSSL 1.1.1 and later is completely different.  You no 
longer need to and should not try to register the locking callbacks.



Pauli

On 17/8/21 11:59 pm, Kumar Mishra, Sanjeev wrote:

Hi All,
I am upgrading the code from OpenSSL 1.0.1 to OpenSSL 3.0.
I am getting compilation errors for deprecated functions and macros 
like "CRYPTO_num_locks()" , "CRYPTO_LOCK" ..etc. But there is not 
any replacement for these functions and macros in OpenSSL 3.0.

How can I handle these compilation errors ?
Should I re-write these functions doing nothing and macros with any 
arbitrary numbers ?
In OpenSSL 3.0 source code file /include/openssl/crypto.h.in, it is 
mentioned that to handle these functions and macros as "no-ops".
Could anybody elaborate the following comment from source code of 
OpenSSL 3.0 (/include/openssl/crypto.h.in) in details...


/*
* The old locking functions have been removed completely without 
compatibility
* macros. This is because the old functions either could not properly 
report

* errors, or the returned error values were not clearly documented.
* Replacing the locking functions with no-ops would cause race condition
* issues in the affected applications. It is far better for them to 
fail at

* compile time.
* On the other hand, the locking callbacks are no longer used. 
Consequently,
* the callback management functions can be safely replaced with no-op 
macros.

*/
# define CRYPTO_num_locks() (1)
# define CRYPTO_set_locking_callback(func)
# define CRYPTO_get_locking_callback() (NULL)
# define CRYPTO_set_add_lock_callback(func)
# define CRYPTO_get_add_lock_callback() (NULL)
/*
* These defines where used in combination with the old locking callbacks,
* they are not called anymore, but old code that's not called might still
* use them.
*/
# define CRYPTO_LOCK 1
# define CRYPTO_UNLOCK 2
# define CRYPTO_READ 4
# define CRYPTO_WRITE 8
.
.
..

Thanks in anticipation,
Sanjeev Kumar Mishra


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others 
or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.

Re: Replacement for AES_set_encrypt_key and AES_encrypt to support 3.0

[Dr Paul Dale]

You don't want to use these and there is no direct replacement.  You 
want to use the EVP calls instead:  EVP_CipherInit_ex2, 
EVP_CipherUpdate, EVP_CipherFinal_ex and friends.


See this manual page:
    https://www.openssl.org/docs/manmaster/man3/EVP_EncryptInit.html


Pauli

On 17/8/21 5:11 pm, Shivakumar Poojari wrote:

Hi All,

       We are upgrading our code to openssl 3.0.

         we need replacement for *AES_set_encrypt_key* and 
*AES_encrypt,* these two functions are in two       different functions


   previously we replaced below functions

    AES_set_decrypt_key() AES_cbc_encrypt() 
to EVP_CipherInit_ex EVP_CipherUpdate
    EVP_CipherFinal_ex as show in the man page example now scenario is 
different


    Now I need *AES_set_encrypt_key *code 
separately**and***AES_encrypt *code separately to use in differnnt    
 places



Thanks,
shiva kumar




Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others 
or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.

Re: One iOS App - 2 OpenSSL libraries.

[Dr Paul Dale]

There shouldn't be a limitation.  Although if two different versions of 
OpenSSL are being used, it is possible that they could interact together 
in odd ways.



OpenSSL will automatically use assembly implementations of algorithms 
unless:


* the "no-asm" option is specified at configuration time;
* the processor is detected, at run time, as being unable to support 
what we supply;

* there isn't such an implementation available.

I'm assuming that this is what you meant by "Bit-Code".


Paul Dale

On 16/8/21 10:57 pm, Goetzke, Arnold (A.P.) wrote:

Hi -

We have a large application, and two vendors are using the OpenSSL 
library in their project.  However, only one of the projects encrypts 
data successfully when joined in our application


Is this a known limitation?

Also, is there a way to enable Bit-Code for iOS when compiling?  I 
don't see build setting to enable Bit-Code in the configuration options.


https://wiki.openssl.org/index.php/Compilation_and_Installation 
<https://wiki.openssl.org/index.php/Compilation_and_Installation>


Thanks for the help!

Arnold

Re: Hi team, I modified openssl code and make test failed. What should I do with the failed cases. Thx in advance.

[Dr Paul Dale]

I suggest working out why they failed and getting them working again.  
You've broken something with your modifications, you need to understand 
what's broken and why before continuing.



Paul Dale

On 14/8/21 9:56 am, Ma Zhenhua wrote:

Hi team,

I modified openssl code and make test failed. What should I do with 
the failed cases. Thx in advance.


Best regards,
Allen

Re: openssl 3.0 genpkey

[Dr Paul Dale]

Ken,

I've created issue #16238 
 for these.  Any chance 
you could add version information or other useful tidbits?


Thanks,

Pauli

On 6/8/21 7:59 am, Ken Goldman wrote:

Should these be posted here or as github issues?  (May be user error)

1

openssl genpkey -algorithm rsa -outform der -out key.der -quiet

returns:

genpkey: Option -quiet needs a value

But the docs don't indicate that a value is needed.

2

openssl genpkey -algorithm rsa -outform der -out key.der -text

Docs say that the unencrypted key should be printed, but it isn't.

3

openssl genpkey  -cipher des3

returns:

genpkey: Use -help for summary.

I tried other values for -cipher but none worked

4

-aes-128-cbc works but is not documented

Re: openssl 3.0 genpkey

[Dr Paul Dale]

GitHub issues would be better.  They are harder to missing accidentally.


Pauli


On 6/8/21 7:59 am, Ken Goldman wrote:

Should these be posted here or as github issues?  (May be user error)

1

openssl genpkey -algorithm rsa -outform der -out key.der -quiet

returns:

genpkey: Option -quiet needs a value

But the docs don't indicate that a value is needed.

2

openssl genpkey -algorithm rsa -outform der -out key.der -text

Docs say that the unencrypted key should be printed, but it isn't.

3

openssl genpkey  -cipher des3

returns:

genpkey: Use -help for summary.

I tried other values for -cipher but none worked

4

-aes-128-cbc works but is not documented

Re: OpenSSL beta testing on Solaris and z/OS

[Dr Paul Dale]

Dennis,

Thanks for the information.  Solaris and z/OS are not tested by the 
project, so it's good to know they aren't too far from working out of 
the box.


We would definitely be interested in a pull request with your fixes at 
some stage -- post 3.0 since it's almost certainly too late now.


Paul Dale


On 4/8/21 1:26 am, Dennis Clarke wrote:

 From another thread :

The OpenSSL team has wondered how many people were trying out 3.0
during the beta period without any way of knowing for sure.



 If your curious about the old legacy Solaris 10 on reasonably new
Fujitsu SPARC64 then I can tell you nearly everything "just works". A
few tests fail and we may as well list them :


Test Summary Report
---
03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
61-test_bio_prefix.t (Wstat: 512 Tests: 4 Failed: 2)
   Failed tests:  1, 3
   Non-zero exit status: 2
90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
Files=239, Tests=2815, 7127 wallclock secs (18.23 usr  2.34 sys +
6784.88 cusr 151.77 csys = 6957.22 CPU)
Result: FAIL

A pile of tweaks were required to get to this point and mostly trivial
items such as the perl scripts and the Configuration of course. I did
go with a debug build and I adjusted the CFLAGS quite a bit. When I have
some data from z/OS then I will bring that also. At this time I really
do understand that no one within the OpenSSL dev team has access to such
machines and operating systems. Saying that they are very strict is an
understatement. However code that compiles on them and passes tests is
generally very highly portable and will run anywhere.  Embedded devices
and tight memory constraints are a separate problem.

Re: OpenSSL Beta 2, report of successful migration

[Dr Paul Dale]

Thanks!

The OpenSSL team has wondered how many people were trying out 3.0 during 
the beta period without any way of knowing for sure.  That you've had 
what seems like a fairly smooth transition is wonderful.



Pauli

On 2/8/21 8:10 pm, Olivier Mascia via openssl-users wrote:

Hello,

Just wanted to report that our private code update to move on from OpenSSL 
1.1.1 to 3.0 Beta 2 is successful.
It revolved around replacing some code still using RSA_ apis directly by proper 
EVP_PKEY_ apis, and some other minor details. Nothing too fancy after some 
effort understanding the new recipes.

On the side of SSL communications, we have found *nothing* to update in our 
code, and though deep testing is still ongoing for some days, there are 
apparently no side-effects.  Of course our use-case exercises only a very 
partial set of the whole toolkit. But as people generally only report problems, 
I thought like reporting success, for a change.

I though have a question, regarding Windows binaries.
(We build our own for x86/amd64 using the documented procedure, the compilers 
installed are Visual Studio 2019, with latest updates).

I take it (might be wrong, because the build scripts are complex to me) that 
the naming convention of binaries for OpenSSL 3 on Windows platform is like 
this:

libcrypto-3.dll (and libssl-3.dll)  for the 32 bits 
(release) builds
libcrypto-3-x64.dll (and libssl-3-x64.dll)  for the 64 bits 
(release) builds

Is this naming convention intended to be stable over the 3.x life?  Or would it 
change for things like libcrypto-3.1.dll (or the like) with releases like 3.1.x?

__
Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit 
freundlichen Grüßen,
Olivier Mascia

Re: Accessing bignums of a RSA key with OpenSSL 3.0?

[Dr Paul Dale]

Try: include/openssl/core_names.h
The names are "n", "e" and "d" in this case.


Pauli


On 30/7/21 10:57 pm, Olivier Mascia via openssl-users wrote:

Dear all,

Testing migration to OpenSSL 3.0.
Got to update some code building a JWK (in relation to ACME LetsEncrypt 
protocols).

Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) 
to extract the bignums needed for inclusion into the JWK:

// Access the numerical components of the certificate RSA keys.
BIGNUM* n;
BIGNUM* e;
BIGNUM* d;
RSA_get0_key(cert.RSAkey(), , , );

( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through 
EVP_PKEY_get0_RSA() )

I understand I should now start straight from the EVP_PKEY and use :

EVP_PKEY_get_bn_param(cert.key(), "name-n?", );
EVP_PKEY_get_bn_param(cert.key(), "name-e?", );
EVP_PKEY_get_bn_param(cert.key(), "name-d?", );

( cert.key() returns EVP_KEY* )

The question is: where can I find the proper names for these bignums out of a 
RSA key?

__
Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit 
freundlichen Grüßen,
Olivier Mascia

Re: OpenSSL 3.0.0 beta1 link issues on Solaris 10

[Dr Paul Dale]

None of the core developers have access to Solaris machines, thus we 
rely on the community for reports and fixes for this kind of thing. 
We're happy to assist and can sometimes identify and fix the problem but 
we still require help testing.


This would best be raised as an issue on GitHub 
[https://github.com/openssl/openssl/issues/new?assignees==issue%3A+bug+report=bug_report.md]. 
This way it is tracked and resource time can be allocated to it -- 
although in this case I suspect it will be the community that cracks it 
for us.


Since you seem to have figured out a work around, including details of 
what you needed to do would be very useful.  Putting them up as a pull 
request would be even better.



Paul Dale


On 26/7/21 7:14 am, Dennis Clarke via openssl-users wrote:

I am not sure what testing is happening with old Solaris 10 but I can
tell you there are still servers out there running. I had no issues with
the configuration stage but, as usual, I do need to make a few tweaks to
Configurations/10-main.conf. Merely to get a consistent set of CFLAGS
that I use for libraries that I may want to single step through. In any
case the link stage fails with a truely massive list of undefined
symbols and it seems as if the previous 1.1.1k libs are being found by
the build process. So I wrote a manual link script and specified the
build directory for the RUNPATH and the library search path however that
resulted in a pile of undefined symbols.

So then I went and deleted my previous 1.1.1k libs and the openssl
binary and tried the manual link once again with success.

Not sure if anyone else runs into this but I would hope that the
previous libs would not be located *before* the new current 3.0.0 libs
that are in the build directory.  Regardless I may need to simply start
over as the new libssl.so.3 seems to have a "NEEDED" libcrypto.so.1.1
and that can't be right.

Here is the result of perl configdata.pm --dump :

alpha$ /opt/bw/bin/perl configdata.pm --dump

Command line (with current working directory = .):

 /opt/bw/bin/perl ./Configure solaris64-sparcv9-cc no-asm
--prefix=/opt/bw shared no-hw no-engine -DPEDANTIC

Perl information:

 /opt/bw/bin/perl
 5.32.0 for sun4-solaris-64-ld

Enabled features:

 aria
 async
 autoalginit
 autoerrinit
 autoload-config
 bf
 blake2
 bulk
 cached-fetch
 camellia
 cast
 chacha
 cmac
 cmp
 cms
 comp
 ct
 deprecated
 des
 dgram
 dh
 dsa
 dso
 dtls
 ec
 ec2m
 ecdh
 ecdsa
 err
 filenames
 gost
 idea
 legacy
 md4
 mdc2
 module
 multiblock
 nextprotoneg
 ocb
 ocsp
 pic
 pinshared
 poly1305
 posix-io
 psk
 rc2
 rc4
 rdrand
 rfc3779
 rmd160
 scrypt
 secure-memory
 seed
 shared
 siphash
 siv
 sm2
 sm3
 sm4
 sock
 srp
 srtp
 sse2
 ssl
 ssl-trace
 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:

 acvp-tests  [default]OPENSSL_NO_ACVP_TESTS
 afalgeng[cascade]OPENSSL_NO_AFALGENG
 asan[default]OPENSSL_NO_ASAN
 asm [option] OPENSSL_NO_ASM
 buildtest-c++   [default]
 capieng [cascade]OPENSSL_NO_CAPIENG
 crypto-mdebug   [default]OPENSSL_NO_CRYPTO_MDEBUG
 devcryptoeng[default]OPENSSL_NO_DEVCRYPTOENG
 dynamic-engine  [cascade]
 ec_nistp_64_gcc_128 [default]OPENSSL_NO_EC_NISTP_64_GCC_128
 egd [default]OPENSSL_NO_EGD
 engine  [option] OPENSSL_NO_ENGINE (skip
engines, crypto/engine)
 external-tests  [default]OPENSSL_NO_EXTERNAL_TESTS
 fips[default]
 fips-securitychecks [cascade]OPENSSL_NO_FIPS_SECURITYCHECKS
 fuzz-afl[default]OPENSSL_NO_FUZZ_AFL
 fuzz-libfuzzer  [default]OPENSSL_NO_FUZZ_LIBFUZZER
 ktls[default]OPENSSL_NO_KTLS
 loadereng   [cascade]OPENSSL_NO_LOADERENG
 makedepend  [unavailable]
 md2 [default]OPENSSL_NO_MD2 (skip crypto/md2)
 msan[default]OPENSSL_NO_MSAN
 padlockeng  [cascade]OPENSSL_NO_PADLOCKENG
 rc5 [default]OPENSSL_NO_RC5 (skip crypto/rc5)
 sctp[default]OPENSSL_NO_SCTP
 trace   [default]OPENSSL_NO_TRACE
 ubsan   [default]OPENSSL_NO_UBSAN
 unit-test   [default]OPENSSL_NO_UNIT_TEST
 

Re: EVP_MAC_init - specify the hash algorithm

[Dr Paul Dale]

Please don't do it the PKEY way :)

Your code should look more like:

   OSSL_PARAMS params[2];
   EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL);
   EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac);
   EVP_MAC_free(mac); /* Now or later is all good and depends on the
   app reusing it or not */

   params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0);
   params[1] = OSSL_PARAMS_construct_end();

   EVP_MAC_init(mac_ctx, key, key_len, params);
   EVP_MAC_update(mac_ctx, data1, data1_len);
   EVP_MAC_update(mac_ctx, data2, data2_len);
   EVP_MAC_update(mac_ctx, data3, data3_len);
   EVP_MAC_final(mac_ctx, out, _size, out_len);
   EVP_MAC_CTX_free(mac_ctx);

There are various other calls that tweak the flow but this is the basic 
idea.



Pauli

On 14/7/21 8:48 am, Thomas Dwyer III wrote:
This seems to work for me in 3.0, passing the EVP_MD to 
EVP_DigestSignInit():


pkey = EVP_PKEY_new_mac_key()
EVP_DigestSignInit()
EVP_DigestSignUpdate()
EVP_DigestSignUpdate()
.
.
.
EVP_DigestSignFinal()


Regards,
Tom.III



On Tue, Jul 13, 2021 at 11:02 AM Ken Goldman > wrote:


Porting to 3.0 ... HMAC_Init_ex() had a place for
the hash algorithm.  EVP_MAC_init() does not,
unless it's embedded in the 'params' parameter.

Any advice?  Or a sample for doing an
HMAC with 3.0?

Re: OpenSSL version 3.0.0-beta1 published

[Dr Paul Dale]

However, I was wondering if anyone has ported/refactored the pkcs11 
engine stuff for OpenSSL 3.0 already?  is this on the TODO list for 
the OpenSC/pkcs11 team?  If I wanted to try to refactor the 
opensc-pkcs11 module, how would I start?


PKCS #11 support is one (of many) possible items that will be considered 
for future versions of OpenSSL.  The technical and management committees 
will be discussing which items are going to be worked on for the 
subsequent release in the not too distant future.


I'll also note that PKCS #11 considerations were prominent through the 
3.0 design process.  A PKCS #11 provider is expected to be possible with 
minimal (hopefully no) changes to the provider / libcrypto interface.



Pauli

Re: Switch hangs for significant amount of time when using RAND_write_file API with openssl version 1.1.1h and above.

[Dr Paul Dale]

My guess would be that OpenSSL is waiting for the system randomness 
source to properly seed.  This was an intentional change.  Without it 
security will likely be lost.


Paul Dale

On 6/5/21 8:34 pm, Sravani Maddukuri via openssl-users wrote:

Hi,

I have updated the openssl version running on the switch from 1.1.1g 
to 1.1.1h and eventually to 1.1.1k.
Starting 1.1.1h, I am observing that the switch hangs for a 
significant amount of time (> 3 minutes) when the call RAND_write_file 
is invoked from the switch software.
The same call (RAND_write_file) invoked from the switch software with 
the earlier versions of openssl (1.1.1g) did not make the switch to 
hang for the noticeable time. Can you please help me understand why 
this behavior is and suggest a solution if any?


Regards,
Sravani

This electronic communication and the information and any files 
transmitted with it, or attached to it, are confidential and are 
intended solely for the use of the individual or entity to whom it is 
addressed and may contain information that is confidential, legally 
privileged, protected by privacy laws, or otherwise restricted from 
disclosure to anyone else. If you are not the intended recipient or 
the person responsible for delivering the e-mail to the intended 
recipient, you are hereby notified that any use, copying, 
distributing, dissemination, forwarding, printing, or copying of this 
e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, 
and destroy any printed copy of it. 

Re: Load and unload of engines at runtime

[Dr Paul Dale]

Why would you believe that ENGINE_register / ENGINE_unregister are the 
calls to load/unload an engine?  These calls are for _after_ the engine 
has been loaded:


   /*- Manage registration of ENGINEs per "table". For each type, there
   are 3
 * functions;
 *   ENGINE_register_***(e) - registers the implementation from 'e'
   (if it has one)
 *   ENGINE_unregister_***(e) - unregister the implementation from 'e'
 *   ENGINE_register_all_***() - call ENGINE_register_***() for
   each 'e' in the list
 * Cleanup is automatically registered from each table when required.
 */

Might I suggest reading the manual pages?  Start with ENGINE_add().


Pauli

BTW: waiting less than a day for a response is a bit impulsive. Most of 
the people who respond here are volunteers.




On 1/5/21 4:30 pm, Mahendra SP wrote:

Hi All,

Could someone please help with this query?

Thanks
Mahendra

On Thu, Apr 29, 2021 at 5:20 PM Mahendra SP > wrote:


Hi All,

We have crypto engines for offloading operations like RSA, digests
and ciphers, hmac etc. We are looking at a way to load and unload
engines at run time. This is needed as we need to use the engine
when needed for crypto operations. Else we plan to use openssl for
the same.

We tried,
-> unregister calls like ENGINE_unregister_XXX calls to force
redirection to openssl
-> Again, ENGINE_register_XXX to redirect to engine.

However, the above methods are not helping. Please suggest a way
to achieve the above requirement.

Thanks
Mahendra

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

[Dr Paul Dale]

Comments inline.

Pauli

On 15/4/21 12:09 am, Bala Duvvuri wrote:

HI Paul,

Thanks a lot for your response, thank you for pointing to 
/providers/implementations/rands/test_rng.c and the code to run NIST test.


Still finding it a bit difficult to wrap around these new APIs

In the old implementation using OpenSSL 1.1.1, to generate random numbers:

a> we have set the callback for custom entropy (using 
RAND_DRBG_set_callbacks) for the RAND_DRBG_get0_master() DRBG instance 
(DRBG defaulted to CTR mode)
b> Also we have set the personalization string using 
RAND_DRBG_instantiate and the reseed interval to 1 using 
RAND_DRBG_set_reseed_interval for both master and public/private DRBG

c> RAND_bytes is used to avail random numbers.

""In summary, we want to use the CTR_DRBG implementation and provide 
our custom entropy/nonce from hardware""


I am not sure if my understanding is clear, can you please let me know 
this basic question how to go about this in OpenSSL 3.0?


1>Will I be able to use the built in DRBG and set a new custom 
provider for the built in DRBG as parent?


Yes, exactly.  This is what I've been saying.



2> OR, is this the approach I need to follow

rand = EVP_RAND_fetch(NULL, "CTR-DRBG", NULL);

Can you let me know how can I link this "rand" to new parent that I 
setup ?


You can't link DRBG's to parents after creation.  This code will use the 
OpenSSL built in entropy source and you won't be able to change it.




3> >> The built in DRBG's don't need the nonce, they will act as per 
SP800-90Ar1 section 9.1 with a nonce available from their parent.
/providers/implementations/rands/seed_src.c is the OpenSSL seed source 
and it doesn't supply nonces.


So does the built in DRBG need a nonce as above statements are 
contradictory?


It can accept a nonce.  However, if one isn't provided it uses a random 
once grabbed from it's parent via the generate call.  The latter path is 
easier.



4> Also, where is the drbg_data defined/looked up in this case for the 
test data vectors


0 acvp_test.c 1341 const struct drbg_st *tst = _data[id];
1 acvp_test.c 1468 ADD_ALL_TESTS(drbg_test, OSSL_NELEM(drbg_data));


Try:

   grep drbg_data test/*




Thanks
Bala

On Wednesday, 14 April, 2021, 05:02:22 pm IST, Dr Paul Dale 
 wrote:



For setting up a parent for a DRBG, look at 
/providers/implementations/rands/test_rng.c which produces seed 
material (test_rng_generate) and nonces (test_rng_nonce).  The built 
in DRBG's don't need the nonce, they will act as per SP800-90Ar1 
section 9.1 with a nonce available from their parent. 
/providers/implementations/rands/seed_src.c is the OpenSSL seed source 
and it doesn't supply nonces.


For the CAVS tests, look at test/acvp_test.c or test/evp_test.c which 
both include code to run NISTs tests.



Pauli

On 14/4/21 8:47 pm, Bala Duvvuri wrote:
1> >>The best way to do this, is to create a provider which acts as a 
seed source and to then use this as the parent of the primary DRBG. 
See, for example, test/testutil/fakerandom.c for how to do this. The 
key is to set up the seed source before the RNG subsystem is first used.


In our case we provide the entropy and nonce from hardware sources (as 
its on embedded platform) as requested by DRBG in older version.
Now, if we setup a custom provider and use it as parent of the primary 
DRBG, its not clear how the entropy and nonce from this provider will 
be accessed, which API is invoked for the entropy/nonce consumption 
(any specific callbacks set)? Can you please explain the steps or 
example of the usage?


2> Also, we need set DRBG for CAVS test (Input: EntropyInput, Nonce, 
PersonalizationString, AdditionalInput, EntropyInputPR, 
AdditionalInput, EntropyInputPR), with OpenSSL 1.1.1, the below steps 
were done:


RAND_DRBG_new(NID_aes_256_ctr, RAND_DRBG_FLAGS, NULL);
RAND_DRBG_set_callbacks // This will setup to return the provided 
entropy and nonce inputs

RAND_DRBG_instantiate // Pass personalization string.
RAND_DRBG_generate

Can you kindly let me know the equivalent steps with OpenSSL 3.0?


Thank you for your help in this.

Thanks
Bala

On Wednesday, 24 March, 2021, 11:56:18 am IST, Dr Paul Dale 
 <mailto:pa...@openssl.org> wrote:



RAND_add() forces a reseed to the DRBGs and uses the passed material 
(not as entropy but as additional input).


EVP_RAND_reseed() is a more direct interface but remember that the 
built in DRBGs are free to ignore what the user claims is /entropy/. 
History has shown us time and again that /entropy/ is often anything but.


The *best* way to do this, is to create a provider which acts as a 
seed source and to then use this as the parent of the primary DRBG.  
See, for example, test/testutil/fakerandom.c for how to do this.  The 
key is to set up the seed source before the RNG subsystem is first used.


If you simply want to replace the built-in DRBGs with a real random 
source, create

Re: Sp800 56a rev3

[Dr Paul Dale]

These are all questions for your FIPS lab.

Pauli

On 15/4/21 4:19 am, Nagarjun J wrote:

Hi,

Suppose if any one submitted for FIPS 140-2 certification in Nov 2020 
, what is the deadline to meet sp800 56 a rev3 revision requirement to 
avoid certificate going into historical list. And if we meet 
requirement before deadline what is the validity of certificate. And 
do we need to test this with old cmvp or new acvp procedure.


Regards
Nag

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

[Dr Paul Dale]

For setting up a parent for a DRBG, look at 
/providers/implementations/rands/test_rng.c which produces seed material 
(test_rng_generate) and nonces (test_rng_nonce).  The built in DRBG's 
don't need the nonce, they will act as per SP800-90Ar1 section 9.1 with 
a nonce available from their parent. 
/providers/implementations/rands/seed_src.c is the OpenSSL seed source 
and it doesn't supply nonces.


For the CAVS tests, look at test/acvp_test.c or test/evp_test.c which 
both include code to run NISTs tests.



Pauli

On 14/4/21 8:47 pm, Bala Duvvuri wrote:
1> >>The best way to do this, is to create a provider which acts as a 
seed source and to then use this as the parent of the primary DRBG. 
See, for example, test/testutil/fakerandom.c for how to do this. The 
key is to set up the seed source before the RNG subsystem is first used.


In our case we provide the entropy and nonce from hardware sources (as 
its on embedded platform) as requested by DRBG in older version.
Now, if we setup a custom provider and use it as parent of the primary 
DRBG, its not clear how the entropy and nonce from this provider will 
be accessed, which API is invoked for the entropy/nonce consumption 
(any specific callbacks set)? Can you please explain the steps or 
example of the usage?


2> Also, we need set DRBG for CAVS test (Input: EntropyInput, Nonce, 
PersonalizationString, AdditionalInput, EntropyInputPR, 
AdditionalInput, EntropyInputPR), with OpenSSL 1.1.1, the below steps 
were done:


RAND_DRBG_new(NID_aes_256_ctr, RAND_DRBG_FLAGS, NULL);
RAND_DRBG_set_callbacks // This will setup to return the provided 
entropy and nonce inputs

RAND_DRBG_instantiate // Pass personalization string.
RAND_DRBG_generate

Can you kindly let me know the equivalent steps with OpenSSL 3.0?


Thank you for your help in this.

Thanks
Bala

On Wednesday, 24 March, 2021, 11:56:18 am IST, Dr Paul Dale 
 wrote:



RAND_add() forces a reseed to the DRBGs and uses the passed material 
(not as entropy but as additional input).


EVP_RAND_reseed() is a more direct interface but remember that the 
built in DRBGs are free to ignore what the user claims is /entropy/.  
History has shown us time and again that /entropy/ is often anything but.


The *best* way to do this, is to create a provider which acts as a 
seed source and to then use this as the parent of the primary DRBG.  
See, for example, test/testutil/fakerandom.c for how to do this.  The 
key is to set up the seed source before the RNG subsystem is first used.


If you simply want to replace the built-in DRBGs with a real random 
source, create a provider and set the appropriate environment/config 
variables.



Pauli


On 24/3/21 4:14 pm, Bala Duvvuri via openssl-users wrote:

Hi All,In OpenSSL 1.1.1 version, we were using RAND_DRBG for random number 
generation.Using "RAND_DRBG_set_callbacks", we were able to call into our 
custom API for entropy and nonce generation.How can this be achieved with EVP_RAND 
implementation i.e. does it allow entropy to be provided? ThanksBala

Re: EVP_MAC_init() in 3.0 alpha 13

[Dr Paul Dale]

Did you attempt to pass NULL for the key and zero for it's length to the 
EVP_MAC_init() call?


Pauli

On 5/4/21 10:51 pm, Hal Murray wrote:

It used to take just a ctx.  Now it also wants a key+length and a params.

I have some simple/hack code to time 2 cases.  The first gives it the key each
time.  The second preloads the key.  That would require an evp per key, but I
might we willing to make that space/time tradeoff.

The each time mode of my old code put the cipher and key into a params array,
then called
   EVP_MAC_CTX_set_params(ctx, params) and then
   EVP_MAC_init(ctx)
That's easy to change.  I just drop putting the key into a params slot and
drop calling set_parms and add the key and parms to EVP_MAC_init.  That worked.

Is there a way to use a preloaded key?  I tried using NULL for key and params
when calling EVP_MAC_init.  It compiles and runs but doesn't get the right
answer.  Is that, or something like it supposed to work?



EVP_MAC_CTX_set_params() seems ugly to me.

My inner loop looks like:
   EVP_MAC_CTX_set_params()
   EVP_MAC_init()
   EVP_MAC_update()
   EVP_MAC_final()

I'm trying to make things go fast.  It's going to have to do string compares
to figure out what I want to do.  I'm working with small blocks of data (48
bytes) so the setup cost is important.  Or I think it is, so I'm trying to
measure it.

The case I'm trying to get working is to move the EVP_MAC_CTX_set_params() out
of the loop.

Re: error: redefinition of ‘struct rsa_meth_st’

[Dr Paul Dale]

You shouldn't be accessing the internal of a private structure. That 
structure was made private for a reason and duplicating it in your 
engine will break when we change the structure's contents.


Your engine should be using the EVP_PKEY_meth_set_* function to do what 
you want (for 1.1.1).  For 3.0, you should be writing a provider instead.



Pauli

On 12/4/21 5:04 am, Shariful Alam wrote:

Hello,
Hope you guys are doing well. I'm trying to develop an RSA engine. My 
engine was somewhat working until I try to integrate my engine with an 
apache httpd server. After installing the httpd from the source code, 
it turns out that, I can't compile my engine anymore. I get the 
following error while I try to compile (it was compiling before and I 
did not make any changes to my engine code).


==

*$gcc -fPIC -c r_engine.c*
*r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
 struct rsa_meth_st {
        ^
In file included from /usr/include/openssl/crypto.h:131:0,
                 from r_engine.c:7:
/usr/include/openssl/ossl_typ.h:147:16: note: originally defined here
 typedef struct rsa_meth_st RSA_METHOD;*

=

and my *struct rsa_meth_st *looks like the following,



*struct rsa_meth_st {

    const char *name;
    int (*rsa_pub_enc) (int flen, const unsigned char *from, unsigned 
char *to, RSA *rsa, int padding);
    int (*rsa_pub_dec) (int flen, const unsigned char *from, unsigned 
char *to, RSA *rsa, int padding);
    int (*rsa_priv_enc) (int flen, const unsigned char *from, unsigned 
char *to, RSA *rsa, int padding);
    int (*rsa_priv_dec) (int flen, const unsigned char *from, unsigned 
char *to, RSA *rsa, int padding);


    int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX 
*ctx);


    int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p, 
const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);


    int (*init) (RSA *rsa);

    int (*finish) (RSA *rsa);

    int flags;

    char *app_data;

    int (*rsa_sign) (int type, const unsigned char *m, unsigned int 
m_length, unsigned char *sigret, unsigned int *siglen, const RSA *rsa);


    int (*rsa_verify) (int dtype, const unsigned char *m, unsigned int 
m_length, const unsigned char *sigbuf, unsigned int siglen, const RSA 
*rsa);


    int (*rsa_keygen) (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb);

};
*

=

My sample skeleton code is here https://pastebin.com/uNXYknEA 



Can anyone please tell me what I'm I doing wrong?

Regards,
Shariful Alam

Re: EVP_MAC_init() in 3.0 alpha 13

[Dr Paul Dale]

Does EVP_MAC_CTX_dup() after the MAC context has been initialised do 
what you want?



Pauli

On 5/4/21 10:51 pm, Hal Murray wrote:

It used to take just a ctx.  Now it also wants a key+length and a params.

I have some simple/hack code to time 2 cases.  The first gives it the key each
time.  The second preloads the key.  That would require an evp per key, but I
might we willing to make that space/time tradeoff.

The each time mode of my old code put the cipher and key into a params array,
then called
   EVP_MAC_CTX_set_params(ctx, params) and then
   EVP_MAC_init(ctx)
That's easy to change.  I just drop putting the key into a params slot and
drop calling set_parms and add the key and parms to EVP_MAC_init.  That worked.

Is there a way to use a preloaded key?  I tried using NULL for key and params
when calling EVP_MAC_init.  It compiles and runs but doesn't get the right
answer.  Is that, or something like it supposed to work?



EVP_MAC_CTX_set_params() seems ugly to me.

My inner loop looks like:
   EVP_MAC_CTX_set_params()
   EVP_MAC_init()
   EVP_MAC_update()
   EVP_MAC_final()

I'm trying to make things go fast.  It's going to have to do string compares
to figure out what I want to do.  I'm working with small blocks of data (48
bytes) so the setup cost is important.  Or I think it is, so I'm trying to
measure it.

The case I'm trying to get working is to move the EVP_MAC_CTX_set_params() out
of the loop.

Re: openssl-users Digest, Vol 77, Issue 6

[Dr Paul Dale]

Vishwanath,

It isn't possible to do what you are wanting.  RAND_METHOD replaces the 
RNG everywhere.  It cannot be done on a per thread process.



Pauli

On 4/4/21 9:55 pm, Vishwanath Mahajanshetty wrote:


Hi Paul,

Thanks for your response. I understand the concern for good random 
numbers; but in this scenario when second thread calls SSL_CTX_new it 
is waiting forever in RAND_priv_bytes(). Looks like entropy functions 
defined by first (bind) thread are very specific for its own use case 
and can’t be used by other treads.


So I am thinking of using default OpenSSL RAND_METHOD for second 
thread and keep first thread (bind) to use its own random number 
generators.


Please let me know how can I make one thread use default RAND_METHOD 
and keep other thread to use its own method. I have gone through 
RAND_bytes() and drbg_bytes() but not getting enough idea. It would be 
really helpful if you point out APIs which help me to achieve this 
requirement.


Thank You,

Vishwanath M

*From: *openssl-users-requ...@openssl.org 
<mailto:openssl-users-requ...@openssl.org>

*Sent: *03 April 2021 02:19 PM
*To: *openssl-users@openssl.org <mailto:openssl-users@openssl.org>
*Subject: *openssl-users Digest, Vol 77, Issue 6

Send openssl-users mailing list submissions to
    openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users 
<https://mta.openssl.org/mailman/listinfo/openssl-users>

or, via email, send a message with subject or body 'help' to
    openssl-users-requ...@openssl.org

You can reach the person managing the list at
    openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: openssl-users Digest, Vol 77, Issue 4 (Dr Paul Dale)


--

Message: 1
Date: Sat, 3 Apr 2021 18:48:48 +1000
From: Dr Paul Dale 
To: openssl-users@openssl.org
Subject: Re: openssl-users Digest, Vol 77, Issue 4
Message-ID: 
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

I would be **very** concerned about bypassing a blocking RAND.? It is
almost certainly blocking because it does not have enough randomness to
satisfy your request.? By skipping this, you are likely getting poor
quality random values and this can effectively negate any security you
are gaining from the encryption.

Good random numbers are fundamental to modern cryptography.? Without
them, there is no security.? I cannot stress this enough.? Do not try to
second guess or bypass the RNG.


Pauli

On 3/4/21 6:41 pm, Vishwanath Mahajanshetty wrote:
>
> Thank You Paul and Matthias for your help.
>
> The reason I am trying to have separate RAND_METHOD for two threads
> is, the first thread which runs DNS *bind* code registers for
> RAND_METHOD through dnssec module in it. It registers via either
> ENGINE_set_default_RAND() or RAND_set_rand_method() based on
> OPENSSL_NO_ENGINE is defined or not. But problem is, under some
> circumstances the random number generator enters into blocking mode
> and starts to wait for some events on some FDs and it blocks in
> select() system call. dst__entropy_getdata() ?from bind code is doing
> this. I am not sure under what cases it enters into blocking mode.
>
> So If I use this RND_METHOD in second thread (basically this thread
> does different task of handling *DoT*, Dns Over TLS, connections,
> which is not related to first thread wrt SSL functionalities), then
> while creating SSL_CTX this thread gets stuck in select() system call
> randomly (happens very rarely as decided by dst__entropy_getdata());
> this can happen at any time of SSL connection lifetime whenever it
> wants to get random data.
>
> I agree with you that we should have done this as separate process
> instead of new thread; but I am trying figure out if I can somehow
> avoid this situation.
>
> As you mentioned, I tried to look into implementation of RAND_bytes()
> and drbg_bytes().
>
> When SSL_CTX_new() calls RAND_bytes(), it calls RAND_get_rand_method()
> which returns RAND_METHOD set by *bind* thread. So if I avoid
> configuring RAND_METHOD in *bind* thread, then RAND_get_rand_method()
> will return *rand_meth *which is OpenSSL default RAND_METHOD; but if I
> do this change bind thread will move away from its RAND_METHOD
> functions and start using OpenSSL default functions which may change
> its behaviour.
>
> So I am still confused how can I do *bind* thread to use its own
> RAND_METHOD and *DoT* thread to use default OpenSSL RAND_METHOD. It
> would be really helpful if you can explain this with little more
> details (are there any APIs I can call from one thread to use its
> specific RAND_METH

Re: openssl-users Digest, Vol 77, Issue 4

[Dr Paul Dale]

I would be **very** concerned about bypassing a blocking RAND.  It is 
almost certainly blocking because it does not have enough randomness to 
satisfy your request.  By skipping this, you are likely getting poor 
quality random values and this can effectively negate any security you 
are gaining from the encryption.


Good random numbers are fundamental to modern cryptography.  Without 
them, there is no security.  I cannot stress this enough.  Do not try to 
second guess or bypass the RNG.



Pauli

On 3/4/21 6:41 pm, Vishwanath Mahajanshetty wrote:


Thank You Paul and Matthias for your help.

The reason I am trying to have separate RAND_METHOD for two threads 
is, the first thread which runs DNS *bind* code registers for 
RAND_METHOD through dnssec module in it. It registers via either 
ENGINE_set_default_RAND() or RAND_set_rand_method() based on 
OPENSSL_NO_ENGINE is defined or not. But problem is, under some 
circumstances the random number generator enters into blocking mode 
and starts to wait for some events on some FDs and it blocks in 
select() system call. dst__entropy_getdata()  from bind code is doing 
this. I am not sure under what cases it enters into blocking mode.


So If I use this RND_METHOD in second thread (basically this thread 
does different task of handling *DoT*, Dns Over TLS, connections, 
which is not related to first thread wrt SSL functionalities), then 
while creating SSL_CTX this thread gets stuck in select() system call 
randomly (happens very rarely as decided by dst__entropy_getdata()); 
this can happen at any time of SSL connection lifetime whenever it 
wants to get random data.


I agree with you that we should have done this as separate process 
instead of new thread; but I am trying figure out if I can somehow 
avoid this situation.


As you mentioned, I tried to look into implementation of RAND_bytes() 
and drbg_bytes().


When SSL_CTX_new() calls RAND_bytes(), it calls RAND_get_rand_method() 
which returns RAND_METHOD set by *bind* thread. So if I avoid 
configuring RAND_METHOD in *bind* thread, then RAND_get_rand_method() 
will return *rand_meth *which is OpenSSL default RAND_METHOD; but if I 
do this change bind thread will move away from its RAND_METHOD 
functions and start using OpenSSL default functions which may change 
its behaviour.


So I am still confused how can I do *bind* thread to use its own 
RAND_METHOD and *DoT* thread to use default OpenSSL RAND_METHOD. It 
would be really helpful if you can explain this with little more 
details (are there any APIs I can call from one thread to use its 
specific RAND_METHOD but other threads continue to use OpenSSL default 
RAND_METHOD?).


Thank You,

Vishwanath M

*From: *openssl-users-requ...@openssl.org 
<mailto:openssl-users-requ...@openssl.org>

*Sent: *02 April 2021 04:58 PM
*To: *openssl-users@openssl.org <mailto:openssl-users@openssl.org>
*Subject: *openssl-users Digest, Vol 77, Issue 4

Send openssl-users mailing list submissions to
    openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users 
<https://mta.openssl.org/mailman/listinfo/openssl-users>

or, via email, send a message with subject or body 'help' to
    openssl-users-requ...@openssl.org

You can reach the person managing the list at
    openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Regarding RAND_set_rand_method (Dr Paul Dale)
   2. RE: Regarding RAND_set_rand_method (Dr. Matthias St. Pierre)


--

Message: 1
Date: Fri, 2 Apr 2021 16:51:28 +1000
From: Dr Paul Dale 
To: openssl-users@openssl.org
Subject: Re: Regarding RAND_set_rand_method
Message-ID: <1781ab4c-2e2b-fa3b-8b3c-fb4fc5bd3...@openssl.org>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

There isn't an easy a way to do what you want in 1.1.1.
RAND_set_rand_method replaces the RNG for all of OpenSSL.? In theory
your RAND_METHOD could detect which thread it is running in and do
different things for each.? I'm not sure this is a good idea however.

Why aren't the random number from your first thread good enough for the
second?? Good random numbers are just that - random.? It should be
impossible to distinguish the two streams.

In OpenSSL 3.0 there are ways to achieve what you're wanting.


Pauli

On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:
>
> Hi,
>
> I have some doubts/questions on how to use methods (for ex:
> RAND_set_rand_method) in multi threaded application which use OpenSSL.
> In my application (running on OpenSSL 1.1.1d) there are two threads
> which use OpenSSL, both threads perform very different operations. The
> issue I am facing is as below:
>
> Thread T1 calls RAND_set_r

Re: Regarding RAND_set_rand_method

[Dr Paul Dale]

There isn't an easy a way to do what you want in 1.1.1. 
RAND_set_rand_method replaces the RNG for all of OpenSSL.  In theory 
your RAND_METHOD could detect which thread it is running in and do 
different things for each.  I'm not sure this is a good idea however.


Why aren't the random number from your first thread good enough for the 
second?  Good random numbers are just that - random.  It should be 
impossible to distinguish the two streams.


In OpenSSL 3.0 there are ways to achieve what you're wanting.


Pauli

On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:


Hi,

I have some doubts/questions on how to use methods (for ex: 
RAND_set_rand_method) in multi threaded application which use OpenSSL. 
In my application (running on OpenSSL 1.1.1d) there are two threads 
which use OpenSSL, both threads perform very different operations. The 
issue I am facing is as below:


Thread T1 calls RAND_set_rand_method() and sets RAND_METHOD structure. 
This is very specific to T1s use case. When thread T2 wants to create 
SSL_CTX it calls SSL_CTX_new() which then calls RAND_priv_bytes(). I 
am observing that the function RAND_priv_bytes() is calling the 
function set by T1 by RAND_METHOD in RAND_set_rand_method().


Essentially RAND_METHOD function set by thread T1 are getting called 
by thread T2.


*Q1: I want to know is there any way to avoid this problem? I want 
thread T2 to call default RAND methods and avoid calling methods set 
by thread T1. This is not only for RAND methods, but for any other 
methods.*


**

Q2: Also, is it possible to run OpenSSL as separate instance per 
thread (where each thread can do its own OpenSSL initialization) so 
that they can avoid above mentioned problem?


Thank you,

Vishwanath M

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Dr Paul Dale]

Perhaps ask Qualys to answer your concerns directly?  They must have a 
reason for including this warning.




Pauli

On 1/4/21 5:43 pm, Jan Just Keijser wrote:

On 31/03/21 19:43, Michael Wojcik wrote:

From: openssl-users  On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To:openssl-users@openssl.org
Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.

What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say 
anything about the practice, though I may have missed something. I had a vague memory 
that some standard or "best practice" guideline somewhere said the server 
should send the chain up to but not including the root, but I don't know what that might 
have been.

On the one hand, including the root doesn't help with path validation: either 
some certificate along the chain is a trust anchor already, in which case 
there's no need to include the root; or it isn't, in which case the peer has no 
reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding 
whether the highest intermediate in the chain is signed by a trusted root if 
that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain 
ends in this root, which you don't currently trust, but maybe you'd like to add 
it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors 
should be added using a trustworthy out-of-band procedure, which this is not -- but I 
suppose it's a conceivable use case.


The only thing I'd like to add to this is that whenever I *do* include 
the root anchor in a website and run Qualys' ssllabs test on it, I get 
a (minor) warning:


Additional Certificates (if supplied)
Certificates provided     3 (5051 bytes)
*Chain issues     Contains anchor*

Unfortunately their documentation does not state *why* they print out 
this warning or why it would be bad, but I normally remove the trust 
anchor from the webserver certificate chain nevertheless. It  could 
very well be that I'm not the only web admin that follows their advice 
in this respect.


JM2CW,

JJK / Jan Just Keijser

Re: Unable to load the FIPs config file OpenSSL 3.0

[Dr Paul Dale]

Our general suggestion is to keep the FIPS configuration in it's own 
file and include that -- this helps when updating.


Does a full path to the providers directory help?
Could you try a build with debugging symbols so it's possible to see 
what's going on better?

Set a breakpoint on OSSL_PROVIDER_load() and see what's happening?


Pauli

On 31/3/21 12:29 am, Bala Duvvuri via openssl-users wrote:

Hi All,

Can you kindly help me with this error while running the below program that 
tries to load the configuration which has the FIPs provider?

The program is built on build machine and to be run on linux MIPS platform and 
below error is seen:

  #include 
   main () {
   OSSL_LIB_CTX *libctx;
   libctx = OSSL_LIB_CTX_new();
   OSSL_PROVIDER_set_default_search_path(libctx, "./providers");
   if (!OSSL_LIB_CTX_load_config(libctx, "openssl.cnf")) {
   fputs("ERROR: OSSL_LIB_CTX_load_config()\n", stderr);
   ERR_print_errors_fp(stderr);
   }
   fprintf(stdout, "Version: %s\n", OpenSSL_version(OPENSSL_VERSION));
}

ERROR: OSSL_LIB_CTX_load_config()
00FFF2406000:error:12800067:DSO support routines:(unknown function):could 
not load the shared 
library:crypto/dso/dso_dlfcn.c:118:filename(./providers/fips.so): 
./providers/fips.so: cannot open shared object file: No such file or directory
00FFF2406000:error:12800067:DSO support routines:(unknown function):could 
not load the shared library:crypto/dso/dso_lib.c:162:
00FFF2406000:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:557:name=fips
00FFF2406000:error:076D:configuration file routines:(unknown 
function):module initialization 
error:crypto/conf/conf_mod.c:242:module=providers, value=provider_sect 
retcode=-1
Version: OpenSSL 3.0.0-alpha13 11 Mar 2021

~ # ls -lrt providers/
-rwxrwxrwx1 rootroot  1748513 Mar 30 13:24 fips.so

~ # echo $LD_LIBRARY_PATH
~ #

Steps done:
1>On build machine, build OpenSSL for the target architecture, Linux MIPs, and 
copy the required binaries on the Linux MIPs box.
2>On Linux MIPs box, run ./openssl fipsinstall -out fipsmod.cnf -module fips.so
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) : RNG : (Continuous_RNG_Test) : Pass
Pass
ECDSA : (KAT_Signature) : Pass
DSA : (KAT_Signature) : Pass
TLS12_PRF : (KAT_KDF) : Pass
PBKDF2 : (KAT_KDF) : Pass
SSHKDF : (KAT_KDF) : Pass
KBKDF : (KAT_KDF) : Pass
HKDF : (KAT_KDF) : Pass
SSKDF : (KAT_KDF) : Pass
X963KDF : (KAT_KDF) : Pass
X942KDF : (KAT_KDF) : Pass
HASH : (DRBG) : Pass
CTR : (DRBG) : Pass
HMAC : (DRBG) : Pass
DH : (KAT_KA) : Pass
ECDH : (KAT_KA) : Pass
RSA_Encrypt : (KAT_AsymmetricCipher) : Pass
RSA_Decrypt : (KAT_AsymmetricCipher) : Pass
RSA_Decrypt : (KAT_AsymmetricCipher) : Pass
INSTALL PASSED

~ # cat fipsmod.cnf
[fips_sect]
activate = 1
install-version = 1
conditional-errors = 1
security-checks = 1
module-mac = 
60:26:6C:C9:2D:86:A2:25:86:44:67:DC:EE:95:8F:1F:A1:84:4E:42:C4:E6:1F:6A:12:24:A3:29:72:58:A4:0E
install-mac = 
41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11
install-status = INSTALL_SELF_TEST_KATS_RUN

3>In the build machine, modify the contents of "openssl.cnf" with above output, 
and build the test program linking with crypto library.

   cat openssl-3.0.0-alpha13/apps/openssl.cnf
   1 openssl_conf = openssl_init
   2
   3 [fips_sect]
   4 activate = 1
   5 install-version = 1
   6 conditional-errors = 1
   7 security-checks = 1
   8 module-mac = 
60:26:6C:C9:2D:86:A2:25:86:44:67:DC:EE:95:8F:1F:A1:84:4E:42:C4:E6:1F:6A:12:24:A3:29:72:58:A4:0E
   9 install-mac = 
41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11
10 install-status = INSTALL_SELF_TEST_KATS_RUN
11
12 [openssl_init]
13 providers = provider_sect
14 alg_section = algorithm_sect
15
16 [provider_sect]
17 default = default_sect
18 fips = fips_sect
19
20 [default_sect]
21 activate = 1
22
23 [algorithm_sect]
24 default_properties = fips=yes

4>Copy the openssl.cnf to the Linux box to "/" and also executed "export 
OPENSSL_CONF=/"

4>Now on executing the test program on Linux box, observing the load error.

Do we need to set any environ variable to get the load working or is any step 
missing/wrong?

This test program has worked fine on my build machine when I build, fipsinstall 
and rebuild my test program and run the test on the build machine.

Your input will help me.

Thanks
Bala

Re: FIPs algorithm code vs default implementation

[Dr Paul Dale]

1> Can you please help to understand the differences in the FIPs algorithm 
implementation code vs default?

  Are there additional validations performed in FIPs code?
There are some additional validations, there are other differences. Grep 
the source code for FIPS_MODULE to find all the code differences.  There 
are other differences.  The FIPS provider offers a cut down selection of 
algorithsm, look at providers/fips/fipsprov.c for these.  The FIPS 
provider also has to run power up selt tests, these are in the 
providers/fips directory.




  Can you point to any API (FIPs and non FIPs version) to make this clear?
One example is for AES XTS mode where the two keys are confirmed to be 
different:
Lines 54 - 63 of providers/implementations/ciphers/cipher_aes_xts.c.  
There are plenty of others, grep for FIPS_MODULE.





2> In normal code, EVP_DigestFinal_ex->HASH_FINAL

   Which API is equivalent to HASH_FINAL in FIPs code? How can we navigate 
to the FIPs code path?
EVP_DisgestFinal_ex is the equivalent.  The decision to use FIPS or not 
is made when fetching the algorithm not when using it.  In use FIPS and 
non-FIPS algorithms are accessed identically.


I'd suggest having a look at the 3.0 design document: 
https://www.openssl.org/docs/OpenSSL300Design.html and the 3.0 wiki 
page: https://wiki.openssl.org/index.php/OpenSSL_3.0.



3> When does "FIPS_MODULE" get defined?
When OpenSSL is being build and a FIPS relevant file is being compiled.  
This symbol is never defined for you when you build your application.



Pauli

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

[Dr Paul Dale]

RAND_add() forces a reseed to the DRBGs and uses the passed material 
(not as entropy but as additional input).


EVP_RAND_reseed() is a more direct interface but remember that the built 
in DRBGs are free to ignore what the user claims is /entropy/. History 
has shown us time and again that /entropy/ is often anything but.


The *best* way to do this, is to create a provider which acts as a seed 
source and to then use this as the parent of the primary DRBG.  See, for 
example, test/testutil/fakerandom.c for how to do this.  The key is to 
set up the seed source before the RNG subsystem is first used.


If you simply want to replace the built-in DRBGs with a real random 
source, create a provider and set the appropriate environment/config 
variables.



Pauli


On 24/3/21 4:14 pm, Bala Duvvuri via openssl-users wrote:

Hi All,

In OpenSSL 1.1.1 version, we were using RAND_DRBG for random number generation.

Using "RAND_DRBG_set_callbacks", we were able to call into our custom API for 
entropy and nonce generation.

How can this be achieved with EVP_RAND implementation i.e. does it allow 
entropy to be provided?

Thanks
Bala

Re: How to store openSSL EVP_MD and EVP_MD_CTX in local buffers

[Dr Paul Dale]

Structures are opaque after OpenSSL 1.0.  There is no way to do what you 
want.


The recommended path is to call EVP_MD_CTX_dup() to create a copy of the 
context and use that the second time around.



Pauli


On 24/3/21 2:03 pm, Vuthur Pavankumar wrote:

Hi All,

I was implementing SHA3 multi-call as below using openSSL version 
openssl-1.1.1j


init:
const EVP_MD *evpmd = EVP_sha3_256();
EVP_MD_CTX *ctx = EVP_MD_CTX_new()
EVP_DigestInit_ex(ctx, evpmd, NULL);
store ctx and evpmd in local buffer. and reuse it for update and final
EVP_MD_CTX_free(ctx)

update:
get ctx and evpmd from local buffer and update ctx with evpmd and pass 
it to  EVP_DigestUpdate method


EVP_DigestUpdate(ctx, msg, msg_len); -> get ctx from  local buffer

Final:
get ctx and evpmd from local buffer and update ctx with evpmd and pass 
it to  EVP_DigestUpdate method

if(shake)
EVP_DigestFinalXOF(ctx, md , mdlen); -> get ctx from  local buffer
else
EVP_DigestFinal_ex(ctx, md, )

Note:
some buggy applications may not call the final call and the memory 
allocated using OpenSSL in Digest init may not be freed.
to avoid it I want to store EVP_MD_CTX and EVP_MD data in a local 
buffer and reuse it instead of storing *ctx and freeing in the final call.


the problem I am facing:
1.declaring below struct and compiling resulted in an error.
error: field 'evpmd_ctx' has incomplete type
error: field 'evpmd' has incomplete type

typedef struct {
uint16_t abc;
uint16_t xyz;
uint16_t reserved1;
uint16_t reserved2;
EVP_MD_CTX evpmd_ctx;
EVP_MD evpmd;
} SHA3Data;

2.same error for sizeof(EVP_MD_CTX ) and sizeof(EVP_MD )

looks like EVP_MD_CTX and EVP_MD data are opaque to applications.

*Do we have any other means to store  EVP_MD_CTX and EVP_MD data in 
local buffers and reuse them in update and Final calls?*


Thanks,
Pavan

Re: Openssl-3.0.0 POST

[Dr Paul Dale]

Have a look at the openssl-fipsinstall manual page.

The self tests are run when the FIPS provider is installed.
You can run the install manually using:

  openssl fipsinstall -module ./fips.so -out fips.cnf -provider_name fips

I think that a verify command will also run them:

  openssl fipsinstall -module ./fips.so -in fips.cnf  -provider_name 
fips -verify


The normal "make test" runs the FIPS self tests.  They run very quickly 
when compared to the old FOM, NIST hasrelaxed the rules significantly.



To run them on demand, have a look at the OSSL_PROVIDER-FIPS and 
OSSL_SELF_TEST_new manual pages.  It's easiest to run them from the 
command line.



Pauli


On 5/2/21 7:48 pm, Nagarjun J wrote:

Hello,

Can any one tell , how to run POST tests in openssl-3.0.0.

Regards,
N

Re: PKCS12 APIs with fips 3.0

[Dr Paul Dale]

Of course OpenSSL 3.0 will support a strict FIPS mode and this will be 
the recommended set up.  By setting the default query to "fips=yes" or 
(better) setting up a library context that has no non-FIPS cryptographic 
implementations and you are in a strictly compliant FIPS mode.


If you want to use the PKCS #12 KDF, then you want something that 
*cannot* currently be FIPS validated --> you are not running in strict 
FIPS mode and need a solution that allows FIPS validated cryptographic 
implementations to be bypassed.



Pauli

On 28/1/21 8:08 pm, Jakob Bohm via openssl-users wrote:

If the context does not limit the use of higher level compositions, then
OpenSSL 3.0 provides no way to satisfy the usual requirement that a
product can be set into "FIPS mode" and not invoke the non-validated
lower level algorithms in the "default" provider.

The usual context is to "sell" (give) products to the US Government or
its contractors that have a "FIPS" box-checking procurement requirement.

On 2021-01-28 10:46, Tomas Mraz wrote:

There is unfortunately no simple straightforward answer to this
question. It really depends on the context.

Anyway OpenSSL 3.0 gives you all the flexibility needed.

Tomas

On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:

Does FIPS 140 or the related legal requirements limit the use of
higher
level compositions such as PKCS12KDF, when using only validated
cryptography for the underlying operations?

On 2021-01-28 09:36, Tomas Mraz wrote:

I do not get how you came to this conclusion. The "true" FIPS mode
can
be easily achieved with OpenSSL 3.0 - either by loading just the
fips
and base provider, or by loading both default and fips providers
but
using the "fips=yes" default property (without the "?").

The PKCS12KDF does not work because it is not an FIPS approved KDF
algorithm so it cannot really work in the "true" FIPS mode. But IMO
this does not mean that PKCS12 keys do not work at all - if you use
right (more modern) algoritm based on PBKDF2 to do the password
based
key derivation, they should work.

That in 1.0.x the PKCS12 worked with the FIPS module with legacy
algorithms it only shows that the "true" FIPS mode was not as
"true" as
you might think. There were some crypto algorithms like the KDFs
outside of the FIPS module boundary.

Tomas Mraz

On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users
wrote:

Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
where
all the non-FIPS algorithms are disabled, but the FIPS-
independent
schemes/protocols in the "default" provider remains available?

Remember that in other software systems, such as OpenSSL 1.0.x
and
MS
CryptoAPI, FIPS mode causes all non-validated algorithms to fail
hard,
so all higher level operations are guaranteed to use only FIPS-
validated
crypto.

On 2021-01-27 02:01, Dr Paul Dale wrote:

You could set the default property query to "?fips=yes".  This
will
prefer FIPS algorithms over any others but will not prevent
other
algorithms from being fetched.

Pauli

On 27/1/21 10:47 am, Zeke Evans wrote:

I understand that PKCS12 cannot be implemented in the fips
provider
but I'm looking for a suitable workaround, particularly
something
that is close to the same behavior as 1.0.2 with the fips 2.0
module.

In my case, the default provider is loaded but I am calling
EVP_set_default_properties(NULL, "fips=yes").  I can wrap
calls
to
the PKCS12 APIs and momentarily allow non-fips algorithms
(ie:
"fips=no" or "provider=default") but that prevents the PKCS12
implementation from using the crypto implementations in the
fips
provider.  Is there a property string or some other way to
allow
PKCS12KDF in the default provider as well as the crypto
methods
in
the fips provider?  I have tried "provider=default,fips=yes"
but
that
doesn't seem to work.

Using the default provider is probably a reasonable
workaround
for
reading in PKCS12 files in order to maintain backwards
compatibility.  Is there a recommended method going forward
that
would allow reading and writing to a key store while only
using
the
fips provider?

Thanks,
Zeke Evans
Micro Focus

-Original Message-
From: openssl-users  On
Behalf
Of
Dr Paul Dale
Sent: Tuesday, January 26, 2021 5:22 PM
To: openssl-users@openssl.org
Subject: Re: PKCS12 APIs with fips 3.0

I'm not even sure that NIST can validate the PKCS#12 KDF.
If it can't be validated, it doesn't belong in the FIPS
provider.


Pauli

On 26/1/21 10:48 pm, Tomas Mraz wrote:

On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote:

On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:

On 2021-01-25 17:53, Zeke Evans wrote:

Hi,


Many of the PKCS12 APIs (ie: PKCS12_create,
PKCS12_parse,
PKCS12_verify_mac) do not work in OpenSSL 3.0 when
using
the fips
provider.  It looks like that i

Re: PKCS12 APIs with fips 3.0

[Dr Paul Dale]

You could set the default property query to "?fips=yes".  This will 
prefer FIPS algorithms over any others but will not prevent other 
algorithms from being fetched.


Pauli

On 27/1/21 10:47 am, Zeke Evans wrote:

I understand that PKCS12 cannot be implemented in the fips provider but I'm 
looking for a suitable workaround, particularly something that is close to the 
same behavior as 1.0.2 with the fips 2.0 module.

In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes").  I 
can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or 
"provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the 
fips provider.  Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the 
crypto methods in the fips provider?  I have tried "provider=default,fips=yes" but that doesn't seem to work.

Using the default provider is probably a reasonable workaround for reading in 
PKCS12 files in order to maintain backwards compatibility.  Is there a 
recommended method going forward that would allow reading and writing to a key 
store while only using the fips provider?

Thanks,
Zeke Evans
Micro Focus

-Original Message-----
From: openssl-users  On Behalf Of Dr Paul 
Dale
Sent: Tuesday, January 26, 2021 5:22 PM
To: openssl-users@openssl.org
Subject: Re: PKCS12 APIs with fips 3.0

I'm not even sure that NIST can validate the PKCS#12 KDF.
If it can't be validated, it doesn't belong in the FIPS provider.


Pauli

On 26/1/21 10:48 pm, Tomas Mraz wrote:

On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote:


On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:

On 2021-01-25 17:53, Zeke Evans wrote:

Hi,

   


Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
provider.  It looks like that is because they try to load PKCS12KDF
which is not implemented in the fips provider.  These were all
working in 1.0.2 with the fips 2.0 module.  Will they be supported
in 3.0 with fips?  If not, is there a way for applications running
in fips approved mode to support the same functionality and use
existing stores/files that contain PKCS12 objects?

   


This is an even larger issue: Is OpenSSL 3.x so badly designed that
the "providers" need to separately implement every standard or
non-standard combination of algorithm invocations?

In a properly abstracted design PKCS12KDF would be implemented by
invoking general EVP functions for underlying algorithms, which
would in turn invoke the provider versions of those algorithms.


This is exactly the way it works. The implementation of PKCS12KDF
fetches the underlying digest algorithm using whatever providers it
has available. So, for example, if the PKCS12KDF implementation needs
to use SHA256, then it will fetch an available implementation for it
- and that implementation may come from the FIPS provider (or any
other provider).

However, in 3.0, KDFs are themselves fetchable cryptographic
algorithms implemented by providers. The FIPS module implements a set
of KDFs - but PKCS12KDF is not one of them. Its only available from
the default provider.

So, the summary is, while you can set things up so that all your
crypto, including any digests used by the PKCS12KDF, all come from
the FIPS provider, there is no getting away from the fact that you
still need to have the default provider loaded in order to have an
implementation of the PKCS12KDF itself - which will obviously be
outside the module boundary.

There aren't any current plans to bring the implementation of
PKCS12KDF inside the FIPS module. I don't know whether that is
feasible or not.


IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
approved KDF algorithm. Besides that KDF should not IMO be needed for
"modern" PKCS12 files. I need to test that though.

Re: PKCS12 APIs with fips 3.0

[Dr Paul Dale]

I'm not even sure that NIST can validate the PKCS#12 KDF.
If it can't be validated, it doesn't belong in the FIPS provider.


Pauli

On 26/1/21 10:48 pm, Tomas Mraz wrote:

On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote:


On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:

On 2021-01-25 17:53, Zeke Evans wrote:

Hi,

  


Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
provider.  It looks like that is because they try to load
PKCS12KDF
which is not implemented in the fips provider.  These were all
working
in 1.0.2 with the fips 2.0 module.  Will they be supported in 3.0
with
fips?  If not, is there a way for applications running in fips
approved mode to support the same functionality and use existing
stores/files that contain PKCS12 objects?

  


This is an even larger issue: Is OpenSSL 3.x so badly designed
that the "providers" need to separately implement every standard
or non-standard combination of algorithm invocations?

In a properly abstracted design PKCS12KDF would be implemented by
invoking general EVP functions for underlying algorithms, which
would in turn invoke the provider versions of those algorithms.


This is exactly the way it works. The implementation of PKCS12KDF
fetches the underlying digest algorithm using whatever providers it
has
available. So, for example, if the PKCS12KDF implementation needs to
use
SHA256, then it will fetch an available implementation for it - and
that
implementation may come from the FIPS provider (or any other
provider).

However, in 3.0, KDFs are themselves fetchable cryptographic
algorithms
implemented by providers. The FIPS module implements a set of KDFs -
but
PKCS12KDF is not one of them. Its only available from the default
provider.

So, the summary is, while you can set things up so that all your
crypto,
including any digests used by the PKCS12KDF, all come from the FIPS
provider, there is no getting away from the fact that you still need
to
have the default provider loaded in order to have an implementation
of
the PKCS12KDF itself - which will obviously be outside the module
boundary.

There aren't any current plans to bring the implementation of
PKCS12KDF
inside the FIPS module. I don't know whether that is feasible or not.


IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
approved KDF algorithm. Besides that KDF should not IMO be needed for
"modern" PKCS12 files. I need to test that though.

Re: OpenSSL 1.1.1g Windows build slow rsa tests

[Dr Paul Dale]

I'd suggest giving a build without the no-asm option a try.  The 
performance difference is usually quite significant.


Statis vs dynamic builds wouldn't normally be associated with such a 
large difference.  If the difference were routinely this large, nobody 
would use dynamic linking.



Pauli

On 21/1/21 10:37 am, Michael Wojcik wrote:

From: openssl-users  On Behalf Of Dr Paul
Dale
Sent: Wednesday, 20 January, 2021 16:19

Try building without the no-asm configuration option.


That was my first thought, but according to Dan's message, the firedaemon 
version is also built with no-asm.

The only relevant differences I see between the two builds are static (Dan's) 
versus dynamic (firedaemon's) linkage:


On 21/1/21 6:18 am, Dan Heinz wrote:



compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090
/nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


/MT uses the static-linked MSVC runtime.


Here is the downloaded binary from
https://kb.firedaemon.com/support/solutions/articles/4000121705
<https://kb.firedaemon.com/support/solutions/articles/4000121705>:
compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
/O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


/MD uses the dynamic-linked MSVC runtime.


Here are my configure parameters:
Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2
no-ssl3 no-zlib no-comp no-pinshared no-ui-console
   -DOPENSSL_NO_DEPRECATED --api=1.1.0

And their configure parameters:
Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console
--api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl
-DOPENSSL_NO_DEPRECATED


Assuming the lack of a space between "VC_WIN64A" and "no-asm" is a typo, 
they're also building with no-asm, and the only significant difference for this case that I can see 
is no-shared. (no-pinshared looks even less likely to affect this test, and does it even have any 
effect when building no-shared?)

Linking with /MT will affect code size and layout, which could adversely affect 
code caching. It's not impossible that would have a factor-of-four penalty on 
compute-bound code. I'm reluctant to conclude that's the problem, though, 
without more evidence.

Unfortunately tracking this down would likely require profiling.

That's assuming Dan is correct about the firedaemon build being configured with 
no-asm.

--
Michael Wojcik

Re: OpenSSL 1.1.1g Windows build slow rsa tests

[Dr Paul Dale]

Try building without the no-asm configuration option.

Pauli

On 21/1/21 6:18 am, Dan Heinz wrote:

Hello,

I’m building openssl 1.1.1g  on multiple platforms and I found that the 
rsa speed tests are significantly slower in my build than on the other 
OS platforms (Linux and macOS).


I downloaded a Windows 64-bit binary distribution of openssl from 
https://kb.firedaemon.com/support/solutions/articles/4000121705 
 as 
they include the configure parameters used for their build.


I ran the speed rsa tests on their openssl Windows 64-bit binary and 
they were much faster than the tests on my build.


Here’s some output.
My openssl binary executed with openssl speed rsa:

Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s

Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s

Doing 4096 bits private rsa's for 10s: 60 4096 bits private RSA's in 10.00s

Doing 4096 bits public rsa's for 10s: 4316 4096 bits public RSA's in 10.02s

OpenSSL 1.1.1g  21 Apr 2020

built on: Wed Jan 20 18:38:14 2021 UTC

options:bn(64,64) rc4(int) des(long) aes(partial) blowfish(ptr)

compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090 
/nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


   sign    verify    sign/s verify/s

rsa 2048 bits 0.024450s 0.000639s 40.9   1563.9

rsa 4096 bits 0.17s 0.002321s  6.0    430.9

Here is the downloaded binary from 
https://kb.firedaemon.com/support/solutions/articles/4000121705 
:
Doing 2048 bits private rsa's for 10s: 1622 2048 bits private RSA's in 
10.02s


Doing 2048 bits public rsa's for 10s: 72622 2048 bits public RSA's in 10.00s

Doing 4096 bits private rsa's for 10s: 255 4096 bits private RSA's in 10.03s

Doing 4096 bits public rsa's for 10s: 18976 4096 bits public RSA's in 10.00s

OpenSSL 1.1.1j-dev  xx XXX 

built on: Wed Jan  6 11:11:12 2021 UTC

options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr)

compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo 
/O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED


   sign    verify    sign/s verify/s

rsa 2048 bits 0.006175s 0.000138s    161.9   7262.2

rsa 4096 bits 0.039338s 0.000527s 25.4   1897.6

That is a little over 4 times faster.

Here are my configure parameters:
Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2 
no-ssl3 no-zlib no-comp no-pinshared no-ui-console 
  -DOPENSSL_NO_DEPRECATED --api=1.1.0


And their configure parameters:
Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console 
--api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl 
-DOPENSSL_NO_DEPRECATED


Both my build and theirs are built with Visual Studio 2015.

Any ideas why my build is so much slower?  Is there something in my 
configuration that might cause this?

Re: Question related to default RAND usage and update with engine RAND

[Dr Paul Dale]

Have you tried RAND_set_rand_method()?

This should replace the RNG with yours.

In 3.0, there will be a different scheme and an engine isn’t the ideal way to 
go.


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




> On 1 Dec 2020, at 1:02 am, Mahendra SP  wrote:
> 
> Hi All,
> 
> We are planning to use our own RAND implementation using an engine. What we 
> observe is, during Openssl init, default RAND gets initialized to openssl 
> RAND.
> Then later we initialize our engine RAND. Even though we make our RAND as 
> default, we see that still openssl uses the initial default RAND.
> 
> Here is what could be happening. In the function RAND_get_rand_method,  
> default_RAND_meth gets initialized to openssl RAND. 
> As there is a NULL check for  default_RAND_meth ,  default_RAND_meth  never 
> gets updated as it is not NULL. 
> Even if engine RAND is registered and available for use,  default_RAND_meth 
> never gets updated.
> 
> Given the code snippet below.
> const RAND_METHOD *RAND_get_rand_method(void)
> {
> const RAND_METHOD *tmp_meth = NULL;
> 
> if (!RUN_ONCE(_init, do_rand_init))
> return NULL;
> 
> CRYPTO_THREAD_write_lock(rand_meth_lock);
> if (default_RAND_meth == NULL) {
> #ifndef OPENSSL_NO_ENGINE
> ENGINE *e;
> 
> /* If we have an engine that can do RAND, use it. */
> if ((e = ENGINE_get_default_RAND()) != NULL
> && (tmp_meth = ENGINE_get_RAND(e)) != NULL) {
> funct_ref = e;
> default_RAND_meth = tmp_meth;
> } else {
> ENGINE_finish(e);
> default_RAND_meth = _meth;
> }
> #else
> default_RAND_meth = _meth;
> #endif
> }
> tmp_meth = default_RAND_meth;
> CRYPTO_THREAD_unlock(rand_meth_lock);
> return tmp_meth;
> }
> 
> Should we remove the NULL check for default_RAND_meth to fix this issue ? Or 
> is there any other way?
> 
> Thanks
> Mahendra
> 

Re: HMAC is deprecated in 3.0 getting error 'HMAC' was not declared in this scope

[Dr Paul Dale]

There is no direct replacement for the MHAC call at this point, EVP_MAC needs 
to be used.  I’d suggest reading the EVP_MAC(3) man page.  There is an example 
down the bottom.

Does SSL_set_mtu() do what you require?


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




> On 27 Nov 2020, at 3:32 am, Narayana, Sunil Kumar  wrote:
> 
> Hi,
> We are trying to upgrade our application from openssl usage 
> of 1.0.2 to openssl 3.0, during which we observe following errors.
> Need help to identify the alternatives.
>  
> Error1 :  error: 'HMAC' was not declared in this scope HMAC(EVP_sha1(), 
> (const void*) cookie_secret, COOKIE_SECRET_LENGTH,
> HMAC is deprecated in 3.0 but not finding the suitable replacement to use in 
> application.
> We feel we can use EVP_MAC API’s, but not sure the exact API which replaces 
> HMAC
>  
>  
> Error2 : error: invalid use of incomplete type 'SSL' {aka 'struct ssl_st'} 
> ssl->d1->mtu = MAX_SEND_PKT_SIZE;
> Our application is trying to set the MTU size but can not access d1 of 
> 'struct ssl_st'.
> Any utility exposed to applications similar to API dtls1_ctrl which is mostly 
> an internal one
>  
>  
> Regards,
> Sunil 
> 
> 
> Notice: This e-mail together with any attachments may contain information of 
> Ribbon Communications Inc. that is confidential and/or proprietary for the 
> sole use of the intended recipient. Any review, disclosure, reliance or 
> distribution by others or forwarding without express permission is strictly 
> prohibited. If you are not the intended recipient, please notify the sender 
> immediately and then delete all copies, including any attachments.

Re: PRNG not available when multiple providers are configured?

[Dr Paul Dale]

Adding:
config_diagnostics = 1
At the same level as the openssl_conf line should produce more output.

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




> On 4 Nov 2020, at 4:41 am, Thomas Dwyer III  wrote:
> 
> On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell  <mailto:m...@openssl.org>> wrote:
> 
> 
> On 03/11/2020 00:55, Thomas Dwyer III wrote:
> > I'm having trouble getting RAND_status() to return 1 when my openssl.cnf
> > has both the default provider and the fips provider configured at the
> > same time:
> > 
> > openssl_conf = openssl_init
> > 
> > [openssl_init]
> > providers = provider_sect
> > 
> > [provider_sect]
> > default = default_sect
> > fips = fips_sect
> > 
> > [default_sect]
> > activate = 1
> > 
> > .include /conf/openssl/fips.cnf
> > 
> > If I remove either default or fips from [provider_sect] then
> > RAND_status() returns 1. If I leave them both specified there,
> > RAND_status() always returns 0. Is this the expected behavior or am I
> > doing something wrong? I understand that I must specify properties when
> > fetching algorithms in order to get deterministic behavior with multiple
> > providers loaded. Is there an analogous API for the PRNG that I'm
> > overlooking?
> > 
> > Interestingly, setting activate=0 for either provider is not sufficient
> > to work around this issue.
> 
> I tested this out and was able to replicate your behaviour.
> 
> The reasons are a little complicated (see below) but the TL;DR summary
> is that there is an error in your config file. The ".include" line
> should specify a config file relative to OPENSSLDIR (or
> OPENSSL_CONF_INCLUDE if it is set). It cannot be an absolute path, and
> hence fips.cnf is not being found.
> 
> 
> This explanation does not match my observations. strace clearly shows my 
> fips.cnf getting opened and read when my openssl.cnf has an absolute path. 
> Likewise, strace shows stat64("fips.cnf", ...) failing (and thus no 
> subsequent open() call) when I use a relative path. Furthermore, the 
> documentation at https://www.openssl.org/docs/manmaster/man5/config.html 
> <https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man5/config.html__;!!GqivPVa7Brio!INBlyBEyGaYipDhT7pzBHbqNWwT_X9g1JEID9D5HZmFB-cmNRMWGUEoRqaZMNvs$>
>  says this should be an absolute path.
> 
> That said, see below..
> 
> 
> 
> I've seen this error a few times now so I'm thinking that we should
> perhaps allow absolute paths. I'm not sure what the reason for
> disallowing them was.
> 
> The reason it works if you comment out the "default" line is because
> that means the only provider left is the FIPS one. But the config line
> for that is faulty and therefore activating it fails. Ultimately we have
> not succesfully activated any provider. When you call RAND_status() it
> will attempt to fetch the RAND implementation and find that no providers
> have been activated. In this case we fallback and automatically activate
> the default provider. Hence you end up with RAND_status() still working.
> 
> If you comment out the "fips" line then it works because it doesn't
> attempt to do anything with the fips provider, successfully activates
> the default provider, and hence RAND_status() works as expected.
> 
> If you have both lines in the config file then it first successfully
> activates the default provider. It next attempts to activate the fips
> provider and fails. The way the config code works is that if any of the
> configured providers fail to activate then it backs out and deactivates
> all of them. At this point we're in a situation where a provider has
> been successfully activated and then deactivated again. The fallback
> activation of the default provider only kicks in if you've not attempted
> to activate any providers by the time you first need one. Therefore the
> default provider doesn't activate as a fallback either. Ultimately you
> end up with no active providers and RAND_status() fails.
> 
> Ah ha! This explanation makes sense to me and indeed pointed me at the real 
> problem. I had recompiled OpenSSL but I forgot to update the hmac in fips.cnf 
> via fipsinstall. So yes, the fips provider was failing to activate because of 
> that. As soon I fixed the hmac RAND_status() started working for me. So 
> THANKS for that! :-)
> 
> 
> Tom.III
> 
> 
> 
> 
> We really should have a way of getting more verbose output in the event
> of config issues like this.
> 
> Matt

Re: PRNG not available when multiple providers are configured?

[Dr Paul Dale]

> Ah ha! This explanation makes sense to me and indeed pointed me at the real 
> problem. I had recompiled OpenSSL but I forgot to update the hmac in fips.cnf 
> via fipsinstall. So yes, the fips provider was failing to activate because of 
> that. As soon I fixed the hmac RAND_status() started working for me. So 
> THANKS for that! :-)

Not producing any diagnostic output for a failed checksum seems like a bug.


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

Re: Integration of new algorithms

[Dr Paul Dale]

Kris,

Dynamically allocate yourself a block of NIDs, one for each algorithm, using 
OBJ_new_nid().

Note also, that there is a preferable option if you are working against the 
upcoming 3.0.  Instead of developing an engine, create a provider.  This avoids 
NIDs completely and was designed from the ground up to support what you want.


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




> On 27 Aug 2020, at 2:21 am, Kris Kwiatkowski  wrote:
> 
> Hello,
> 
> I'm working on development of OpenSSL ENGINE that integrates
> post-quantum algorithms (new NIDs). During integration I
> need to modify OpenSSL code to add custom function, but would
> prefer not to need add anything to OpenSSL code (so engine
> can be dynmicaly loaded by any modern OpenSSL).
> 
> So, In three cases, namely when the code is in callbacks for keygen,
> encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt 
> and EVP_PKEY_keygen) I need to get NID of the scheme. The problem
> is that, those functions are called with EVP_PKEY_CTX object
> provided as an argument. The NID is stored in the 
> EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API
> which would return that value.
> 
> I've added a simple function that returns pkey_id from the ctx, but
> that means that I need to change OpenSSL code. Is there any way
> to get NID without changing OpenSSL?
> 
> Kind regards,
> Kris
> 
> 
> 
> 

Re: New NID for acmeIdentifier

[Dr Paul Dale]

This would require a line in crypto/objects/objects.txt and a "make update”.
A pull request would be the way to get this in.

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




> On 26 Aug 2020, at 11:41 pm, Angus Robertson - Magenta Systems Ltd 
>  wrote:
> 
> Is it possible for a new NID and object to be added to support creating
> and checking the Let's Encrypt ACME TLS-ALPN-01 challenge in which a
> temporary X509 certificate is created with a specific X509v3 extension
> containing shared information.
> 
> Currently, I get a new NID with: 
> 
> OBJ_create('1.3.6.1.5.5.7.1.31','acmeIdentifier','X509v3 ACME
> Identifier')
> 
> Angus
> 
> 
> 

Re: openssl fipsinstall

[Dr Paul Dale]

The fipsinstall program runs the platform tests.  I.e. you need to run 
fipsinstall on the device at some point.


> Or are you suggesting that the presence of a standalone tool might influence 
> the contents of such a security policy?

Yes.  Well maybe.  I’ll posit the possibility at the next planning meeting.


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




> On 28 Jul 2020, at 9:51 am, Thomas Dwyer III  wrote:
> 
> On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale  <mailto:paul.d...@oracle.com>> wrote:
> These are questions better asked of a FIPS lab since they are the experts and 
> we are not.
> 
> 
> 
> That is a fair response.
> 
> 
> I expect that your alternative installation process’s validity will depend on 
> the security policy and what it says needs to be done.  This hasn’t been 
> written yet so there is no answer at this point.
> 
> Skipping the self tests is definitely not permitted.  The full suite of self 
> tests *must* be run before the module can be used.
> 
> 
> 
> Oops, I didn't mean to suggest skipping the self-tests. I was talking about 
> the callback that fipsinstall currently uses to display results and/or inject 
> faults in the self-tests. I don't think I need that. As long as 
> OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the 
> self-tests passed at some point.
> 
> 
> 
> You question prompts the possibility of making fipsinstall a standalone 
> executable, this is something we could look into if we get time.  I expect 
> we’d look favourably on a pull request that allowed either or both options.
> 
> 
> 
> This is encouraging. However, since there is no draft security policy written 
> yet would this be premature? Or are you suggesting that the presence of a 
> standalone tool might influence the contents of such a security policy?
> 
> 
> Thanks,
> Tom.III
> 
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 28 Jul 2020, at 6:19 am, Thomas Dwyer III > <mailto:tom...@tomiii.com>> wrote:
>> 
>> Hi all,
>> 
>> I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with 
>> very limited flash space. We need and use libcrypto and libssl but we have 
>> no need for the openssl binary. To date it was never necessary to ship this 
>> utility in our product. Now with OpenSSL 3.0 it appears the only way to get 
>> FIPS support is to run "openssl fipsinstall ..." to create a FIPS config 
>> file to be included by the main config file. However, at nearly 1MB in size 
>> this binary is prohibitively large.
>> 
>> I am able to reproduce the output of "openssl fipsinstall ..." with a 
>> (considerably smaller) standalone tool that links with libcrypto and 
>> generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear 
>> on what the actual FIPS requirements are for this. Would I still be 
>> considered FIPS compliant if I use my own standalone tool instead of the 
>> openssl binary to generate the FIPS config? I presume I don't need to bother 
>> with the self-test callback and that it only matters whether or not 
>> OSSL_PROVIDER_load(NULL, "fips") succeeds?
>> 
>> 
>> Thanks,
>> Tom.III
>> 
> 

Re: openssl fipsinstall

[Dr Paul Dale]

These are questions better asked of a FIPS lab since they are the experts and 
we are not.

I expect that your alternative installation process’s validity will depend on 
the security policy and what it says needs to be done.  This hasn’t been 
written yet so there is no answer at this point.

Skipping the self tests is definitely not permitted.  The full suite of self 
tests *must* be run before the module can be used.


You question prompts the possibility of making fipsinstall a standalone 
executable, this is something we could look into if we get time.  I expect we’d 
look favourably on a pull request that allowed either or both options.

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




> On 28 Jul 2020, at 6:19 am, Thomas Dwyer III  wrote:
> 
> Hi all,
> 
> I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with 
> very limited flash space. We need and use libcrypto and libssl but we have no 
> need for the openssl binary. To date it was never necessary to ship this 
> utility in our product. Now with OpenSSL 3.0 it appears the only way to get 
> FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file 
> to be included by the main config file. However, at nearly 1MB in size this 
> binary is prohibitively large.
> 
> I am able to reproduce the output of "openssl fipsinstall ..." with a 
> (considerably smaller) standalone tool that links with libcrypto and 
> generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear 
> on what the actual FIPS requirements are for this. Would I still be 
> considered FIPS compliant if I use my own standalone tool instead of the 
> openssl binary to generate the FIPS config? I presume I don't need to bother 
> with the self-test callback and that it only matters whether or not 
> OSSL_PROVIDER_load(NULL, "fips") succeeds?
> 
> 
> Thanks,
> Tom.III
> 

Re: OpenSSL user guide for 1.1.1g

[Dr Paul Dale]

There is not and never will be FIPS support for OpenSSL 1.1.1.

You’ll have to wait for the upcoming 3.0 release for FIPS support.


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




> On 25 Jul 2020, at 12:32 am, Faraj Rabby  wrote:
> 
> Hi,
> I am looking for OpenSSL 1.1.1g related user guide or any documentation. I 
> could not find it out. I am getting only the OpenSSL FOM versions. But I need 
> OpenSSL FIPS run time module version 1.1.1g. If you have this please share 
> with me.
> Thanks,
> Faraj
>  
>  
>  
> 
>  
> Assess | Enhance | Validate
>  
> <https://www.linkedin.com/company/corsec-security/>
>  <https://twitter.com/CorsecSecurity> 
> <https://www.facebook.com/CorsecInc/> 
> <https://www.youtube.com/channel/UC_OVHivpw50dUgeHP6GqcGQ> 
> Faraj Rabby
> Certification Analyst
> O: 703.267.6050 x139
> F: 703.267.6810
> E: fra...@corsec.com <mailto:fra...@corsec.com>
> www.corsec.com <http://www.corsec.com/>

Re: OpenSSL shared library in FIPS mode

[Dr Paul Dale]

OpenSSL 1.0.2 ceased being supported at the beginning of this year.

If you are deviating in any way from the prescribed build instructions (you did 
read the security policy didn’t you?) you are not FIPS compliant.
Not using the OpenSSL Makefile is such a deviation.  My suspicion is that you 
are not and never have been FIPS compliant.



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




> On 7 Jul 2020, at 3:36 pm, Shirisha Dasari via openssl-users 
>  wrote:
> 
> Hi All,
> 
> We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS 
> compliance. Post integration, we have been able to run in FIPS mode, with all 
> self-tests passing as well. However, we seem to be encountering issues in 
> creation and parsing of ECDSA keys.
> 
> A little background on how we build the shared libcrypto library:
> 
> TARGET: x86_64 
> BUILD HOST: x86_64
> 
> We do not use the OpenSSL Makefile to build the OpenSSL source. Our build  
> infrastructure  creates multiple static archives from the OpenSSL crypto 
> source and finally creates a libcrypto.a from these archives as required by 
> fipsld. The fipscanister.o and libcrypto.a are archived to create the final 
> libcrypto.a and passed onto fipsld for creation of a dynamic library, 
> libcrypto.so. fips_premain_dso gets built as a part of the build process too 
> for generation of signature. These steps mimic the OpenSSL opensource 
> Makefile.
> 
> fipsld embeds the signature into the final libcrypto.so successfully and we 
> are able to get into FIPS mode successfully at run time. Self-tests pass as 
> well.
> 
> Issue:
> 
> While trying to use ECDSA host keys for OpenSSH, we noticed that parsing of 
> ECDSA key fails. DSA and RSA key creation and parsing do not have this issue. 
> Note that the ECDSA key was generated in FIPS mode and is being parsed in 
> FIPS mode itself.
> 
> root@localhost:/home/admin#  openssl ec -in ssh_host_key_ecdsa -text -noout
> read EC key
> unable to load Key
> 140020611143360:error:10067066:elliptic curve 
> routines:ec_GFp_simple_oct2point:invalid 
> encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370:
> 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC 
> lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172:
> 140020611143360:error:100D508E:elliptic curve 
> routines:ECKEY_PRIV_DECODE:decode 
> error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256:
> 140020611143360:error:0606F091:digital envelope 
> routines:EVP_PKCS82PKEY:private key decode 
> error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92:
> 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 
> lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142:
> root@localhost:/home/admin# 
> 
> A portion of the sample ECDSA key generated with curve secp384r1 via 
> ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f  ssh_host_key_ecdsa" is 
> provided below:
> 
> -BEGIN PRIVATE KEY-
> MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD
> 
> 
> -END PRIVATE KEY-
> 
>  A few questions related to this:
> 
> 1) Is there a specific need to build the OpenSSL source only via the provided 
> Makefile? 
> 2) FIPS self test for ECDSA passes but the key creation/parsing fails. Could 
> this indicate that the FIPS module APIs are not getting invoked in the case 
> of ECDSA?
> 
> -- 
> Thanks & Regards,
> Shirisha.

Re: PKEY CMAC timings

[Dr Paul Dale]

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  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 16225   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 16496   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 levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/

Re: PKEY CMAC timings

[Dr Paul Dale]

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  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 16434   0.434  475ac1c053379e7dbd4ce80b87d2178e
> AES-192  24 48 16442   0.442  c906422bfe0963de6df50e022b4aa7d4
> AES-256  32 48 16453   0.453  991f4017858de97515260dd9ae440b06
> 
> 1.1.1g improved:
> AES-128  16 48 16230   0.230  475ac1c053379e7dbd4ce80b87d2178e
> AES-192  24 48 16252   0.252  c906422bfe0963de6df50e022b4aa7d4
> AES-256  32 48 16252   0.252  991f4017858de97515260dd9ae440b06
> 
> 3.0.0 alpha3:
> AES-128  16 48 16815   0.815  475ac1c053379e7dbd4ce80b87d2178e
> AES-192  24 48 16831   0.831  c906422bfe0963de6df50e022b4aa7d4
> AES-256  32 48 16846   0.846  991f4017858de97515260dd9ae440b06
> 
> 3.0.0-alpha3 improved:
> AES-128  16 48 16500   0.500  475ac1c053379e7dbd4ce80b87d2178e
> AES-192  24 48 16515   0.515  c906422bfe0963de6df50e022b4aa7d4
> AES-256  32 48 16530   0.530  991f4017858de97515260dd9ae440b06
> 
> Thanks again.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 

Re: Asymetric crypto and OpenSSL 3.0 deprecated functions

[Dr Paul Dale]

I’ll note that encryption is _not_ an integrity check.  Depending on how the 
AES encryption is done, this could be a significant hole.


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




> On 25 May 2020, at 10:12 pm, Tomas Mraz  wrote:
> 
> On Mon, 2020-05-25 at 13:20 +0200, Emmanuel Deloget wrote:
>> Hello everybody,
>> 
>> I'm pretty sure this has already been discussed somewhere but
>> grepping
>> through the whole openssl-user list does not gave me the answer I'm
>> searching for, so here am I.
>> 
>> In my development I'm using a idiom that's not as widely used as I
>> thought (as I get it after multiple days of searching out there). In
>> order to securely distribute a binary, I encrypt it using an AES key
>> and the AES key itself is encrypted using a /private/ RSA key I own.
>> Only owners of the /public/ key (which, as it is a publilc key, may
>> leak) can decrypt the AES key, and therefore the binary. The reason
>> why I do this is that I cannot encrypt using the recipient public key
>> because I don't know how many different recipient I have when I
>> generate the encrypted binary ; and generate the binary on request is
>> not feasible.
>> 
>> With this idiom, recipient can check that I crypted the binary, and
>> the binary itself cannot be decrypted unless you're a recipient (i.e.
>> you have the public key). This has worked well for a few years.
>> 
>> Of course, in order to do this I rely on RSA_private_encrypt() and
>> RSA_public_decrypt() because EVP_PKEY_encrypt() / EVP_PKEY_decrypt()
>> cannot be used(*).
>> 
>> So, after that long introduction, here is my question : is there any
>> OpenSSL 3.0 sanctionned, EVP_PKEY-based way to crypt using a private
>> key and decrypt using a public key?
>> 
>> While I fully understand the need to streamline the library interface
>> and to remove the low-level RSA functions, it seems to me that not
>> allowing this is going to be problematic for those who, like me, rely
>> on public key decryption in their process. I also fully understand
>> that it's not the prefered way to do it but I (and some others, I
>> guess) deal with a use case which is not ideal here, and the
>> possibility to use asymetric crypto in this way really saves me.
>> 
>> Best regards,
>> 
>> -- Emmanuel Deloget
>> 
>> (*) tests on OpenSSL 1.0.2 (Ubuntu 16.04) and OpenSSL 1.1.1c (Ubuntu
>> 19.04) shows that it segfaults in EVP_PKEY_decrypt() when feeded with
>> a public key. In OpenSSL 3.0, EVP_PKEY_decrypt() does not appear to
>> be
>> able to decrypt using a RSA public key (it calls
>> RSA_private_decrypt()
>> internally, via rsa_decrypt()).
> 
> The proper protocol would be to just sign the binary by your private
> RSA key and encrypt it with a symmetric key, that you directly pre-
> distribute to your recipients via the same channel that you now use to
> distribute your public RSA key.
> 
> It would have practically the same properties and would not use the RSA
> private encryption directly.
> 
> 
> -- 
> 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.]
> 
> 

Re: Extracting the public modulus from an RSA public key?

[Dr Paul Dale]

Might I suggest reading the documentation?

RSA_get0_n() is the function you are wanting.


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




> On 6 May 2020, at 2:20 pm, Thomas Dwyer III  wrote:
> 
> I'm porting some old legacy code from OpenSSL 1.0.2 to OpenSSL 3.0.0. A 
> portion of this code reads X509 certificates, extracts the public key, and 
> passes it to firmware that I cannot modify. Unfortunately, this legacy 
> firmware API was very poorly designed such that the public key is passed in a 
> way similar to:
> 
> RSA *rsa = get_pubkey_from_cert(...)
> BIGNUM *bn = rsa->n;
> int len = BN_num_bytes(bn);
> unsigned char *buf = malloc(len);
> BN_bn2bin(bn, buf);
> pubkey_to_firmware(buf, len);
> 
> Yuck. Ignoring the fact that this firmware appears to assume a constant 
> exponent 'e', I cannot find a way to extract the modulus 'n' from the RSA 
> key. I understand this is intentional. The only solution I could find is to 
> print the key to a buffer via EVP_PKEY_print_public(), parse the result to 
> extract the modulus into a giant hex string, and then BN_hex2bn() that back 
> into a BIGNUM. Is there a better way?
> 
> 
> Thanks,
> Tom.III
> 

Re: liblegacy.a does not work unless compiled with -static

[Dr Paul Dale]

I’ve been wondering if an option to build the legacy provider into libcrypto 
(like the null and default providers) is worthwhile.

Given this conservation, it seems it might be.


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




> On 2 May 2020, at 5:30 pm, Richard Levitte  wrote:
> 
> On Fri, 01 May 2020 19:22:13 +0200,
> Salz, Rich via openssl-users wrote:
>> 
>> Hm, so DSO support is a requirement for legacy crypto now?  That
>> probably needs to be made explicit, and see if the project gets
>> pushback.
> 
> No.  When DSO support is turned off, the legacy provider code becomes
> part of libcrypto, in an inaccessible state (in other words, you still
> have to "load" it).
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/

Re: New inlcudes needed for OpenSSL V1.1.1 sockets

[Dr Paul Dale]

All of the include files mentioned are standard ones which have always been 
used.
You are building 1.1.1 differently to 1.0.2.  Debug your build environment 
first.


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




> On 31 Mar 2020, at 7:56 pm, Balázs Horváth  
> wrote:
> 
> Thanks for Your answer!
>  
> I was not clearly describing our problem, sorry! Our project is for embedded 
> devices running on MIPS processors. The system has a special OS, not Linux.
> The development system is under Linux, and we are compiling OpenSSL with 
> cross compile option for MIPS. We also compile the code for Linux, so that we 
> have a simulation of the embedded system, that can be easily debugged under 
> Linux.
> Our problem is, that the OpenSSL V1.1.1d needs includes, that are nonexistent 
> for MIPS in our development system. These headers were not needed for 1.0.2.
>  
> My question is not a 100% OpenSSL question. But I think, as OpenSSL is widely 
> used on non-Linux/Windows/… systems, the question is legitime to ask, what to 
> use on special systems? Or why are these headers needed now?
> The programmer, who changed the code, probably had an idea about that.
>  
> Best regards,
> Balazs
> 
> Michael Wojcik  <mailto:michael.woj...@microfocus.com>> ezt írta (időpont: 2020. márc. 30., 
> H, 20:20):
> From: openssl-users  <mailto:openssl-users-boun...@openssl.org>> on behalf of Balázs Horváth 
> mailto:balazs.horvath.em...@gmail.com>>
> Sent: Monday, March 30, 2020 10:00
> 
> > Following extra includes are needed:
> > arpa/inet.h
> > netinet/tcp.h
> > netinet/in.h
> > strings.h
> > netdb.h
> > sys/socket.h
> > sys/ioctl.h
> > sys/un.h
> 
> These are system headers, not OpenSSL headers. OpenSSL has no control over 
> them.
> 
> > For Linux the includes under /usr/include work, but for MIPS they give 
> > compile errors.
> 
> Then you're using the wrong headers for the MIPS compilation. To be honest, 
> it's not clear to me what you're doing, because Linux is an operating system 
> (or more precisely a kernel), and MIPS is a processor family.
> 
> > What should we use for MIPS?
> 
> This is not an OpenSSL question. It's a cross-compilation question (I think, 
> since I'm not sure what you're actually trying to do), and so depends on your 
> cross-compilation toolchain.
> 
> 
> 

Re: OpenSSL 3.0

[Dr Paul Dale]

You should be able to set the environment variable OPENSSL_CONF to 
test/fips.cnf which will then load a FIPS only configuration.

Teething problems are expected.  Not everything has been activated in the FIPS 
module but enough has to do some TLS.


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




> On 27 Feb 2020, at 6:00 am, Salz, Rich via openssl-users 
>  wrote:
> 
>>That's 5 weeks from now, I'd thought the basic structure might be present 
>> now.
> 
> It is.   You probably have to look at the tests to see how to use things.
> 

Re: CRYPTO_secure_malloc_init() fails without error message

[Dr Paul Dale]

> CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, OPENSSL_MIN_HEAP_SIZE);

I’d strongly suggest not passing the same value in the second position.  This 
parameter sets the minimum block size that can be allocated in the secure heap. 
 The init call returns an error in this situation.  Do this instead: 
CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, 16);



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




> On 21 Feb 2020, at 8:33 pm, Clay Shields  wrote:
> 
> Unfortunately that didn’t seem to be it. Updating my code to verify that I am 
> root and running it:
> 
> Output:
> 
> The effective user id is  0
> The real user id is  0
> failed to init openssl secure heap the error may be (null)
> 
> Code:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define OPENSSL_MIN_HEAP_SIZE 65536
> 
> 
> int main(){
> 
>  SSL_load_error_strings();
>  SSL_library_init ();
>  OpenSSL_add_all_algorithms ();
> 
>  uid_t uid, euid;
>  uid = getuid();
>  euid = geteuid();
>  printf("The effective user id is  %d\n", (int) geteuid());
>  printf("The real user id is  %d\n", (int) getuid());
> 
>  // Initialize the OPENSSL secure heap space for key storage
>  int ret = CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, 
> OPENSSL_MIN_HEAP_SIZE);
> 
>  if (ret == 0){
>printf("failed to init openssl secure heap the error may be %s\n", 
> ERR_reason_error_string(ERR_get_error()));
>  }
> 
> }
> 
> 
>> On Feb 20, 2020, at 6:31 PM, Salz, Rich  wrote:
>> 
>> Are you running as root?  If not, that's likely to be the problem.
>> 
> 

Re: Are RAND_bytes and RAND_priv_bytes thread safe?

[Dr Paul Dale]

Yes.


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




> On 11 Feb 2020, at 9:56 am, Hal Murray  wrote:
> 
> I didn't find any mention of threads in their man pages.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 

Re: openssl-fips-2.0.16 : RSA key generation !!

[Dr Paul Dale]

There are transitions ahead to remove FIPS 186-2 as a standard.  At the moment 
all is good, later in this year some things will disappear and be invalid.
The OpenSSL project is aware of the situation but has not yet made a decision 
about the path to follow.  One thing we can say is that the old FOM will not be 
revalidated.


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




> On 2 Jan 2020, at 3:11 pm, Hareesh D  wrote:
> 
> Hi,
> 
> In the openssl-fips-2.0.16 version, I see that some validations are missing 
> (generating probable primes P, Q as part of RSA key generation) which are 
> mentioned in NIST.FIPS.186-4.pdf.
> 
> B.3.3 -> Process : Points 4.4, 4.7, 5.4, 5.5 and 5.8.
> 
> Can someone please confirm this behaviour.
> 
> Thanks !!