Re: openssl 3.0 fips provider and low level APIs

[Tomas Mraz]

All the providers can use the low-level APIs internally to implement
crypto algorithms. The FIPS provider however includes all the low level
implementations as a separately built and statically linked code.

That means you cannot use the low-level calls in an application and
still be FIPS compliant as the low-level API calls called from an
application are implemented by the libcrypto library and not the FIPS
provider.

Tomas Mraz, OpenSSL

On Tue, 2022-05-03 at 10:12 -0500, Joy Latten wrote:
> Hi,
> I understand that low-level APIs have been deprecated in version 3. I
> have been playing some with the fips provider trying to understand
> the config options to use with it. I noticed that the fips provider
> source code includes a few low level APIs like SHA256_Init(). 
> Is it correct to conclude that although use of the low level APIs are
> deprecated, perhaps for a grace period for transitioning they are
> permitted in the fips provider?
> 
> Thanks for all help!
> regards,
> Joy
>   
>    

-- 
Tomáš Mráz, OpenSSL

Re: OpenSSL 3.0 different behaviour on smaller DH groups?

[Michael Richardson]

Simon Chopin  wrote:
> This test suite fails several times with a failed call to
> EVP_PKEY_derive_set_peer, without much more details:
> 
https://github.com/net-ssh/net-ssh/blob/master/test/transport/kex/test_diffie_hellman_group14_sha1.rb

> However, the *exact same* test suite works, with the only difference
> being that the failing suite uses the DH group 14, which is 2048bits,
> whereas the one that passes uses the group 1, which the Internet tells
> me is 768bits.

DH groups of 768bits are considered too weak.
I wonder if openssl 3 is declining to do anymore, and/or has been compiled
with an option to drop support for that size.
(I have no knowledge of that part of openssl)




signature.asc
Description: PGP signature

Re: OpenSSL 3.0 LTS

[The Doctor via openssl-users]

On Fri, Mar 04, 2022 at 02:31:01PM +, Short, Todd wrote:
> Apple uses LibreSSL, not OpenSSL, in their recent OSes:
> 
> ~$ openssl version -a
> LibreSSL 2.8.3
> built on: date not available
> platform: information not available
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
> compiler: information not available
> OPENSSLDIR: "/private/etc/ssl"
> ~$ uname -mprsv
> Darwin 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; 
> root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64 i386
> ~$
>

This is goofy.  So we update to openssl 3 and Apple clients get locked out.

Libresll should get its act together.

> --
> -Todd Short
> // tsh...@akamai.com
> // ???One if by land, two if by sea, three if by the Internet."
> 
> > On Mar 4, 2022, at 9:26 AM, The Doctor via openssl-users 
> >  wrote:
> > 
> > On Fri, Mar 04, 2022 at 11:04:00AM +, Matt Caswell wrote:
> >> OpenSSL 3.0 has recently been designated as a Long Term Support (LTS)
> >> release. This means that it will now be supported until 7th September
> >> 2026 (5 years after its initial release).
> >> 
> >> Our previous LTS release (1.1.1) will continue to be supported until
> >> 11th September 2023.
> >> 
> >> We encourage all users to upgrade to 3.0.
> >> 
> > 
> > 
> > Though I full agree, what is Apple's stand on gettng their clients upgraded
> > to openssl3 compilance?
> > 
> >> Yours,
> >> The OpenSSL Project Team
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> > doctor@@nl2k.ab.ca
> > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> > rising!
> > Look at Psalms 14 and 53 on Atheism 
> > https://urldefense.com/v3/__https://www.empire.kred/ROOTNK?t=94a1f39b__;!!GjvTz_vk!D9V7BUjD7_WYZb-MFNIM1B5vPCGGhjFNF3Bh8w6c_691AQgafZRZJZmvQfcb$
> > Siding with murders against the innocent is progress only to fools. 
> > -unknown Beware 
> > https://urldefense.com/v3/__https://mindspring.com__;!!GjvTz_vk!D9V7BUjD7_WYZb-MFNIM1B5vPCGGhjFNF3Bh8w6c_691AQgafZRZJRTcE69B$
> 



-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
Siding with murders against the innocent is progress only to fools. -unknown 
Beware https://mindspring.com

Re: OpenSSL 3.0 LTS

[Short, Todd via openssl-users]

Apple uses LibreSSL, not OpenSSL, in their recent OSes:

~$ openssl version -a
LibreSSL 2.8.3
built on: date not available
platform: information not available
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: information not available
OPENSSLDIR: "/private/etc/ssl"
~$ uname -mprsv
Darwin 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; 
root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64 i386
~$

--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."

> On Mar 4, 2022, at 9:26 AM, The Doctor via openssl-users 
>  wrote:
> 
> On Fri, Mar 04, 2022 at 11:04:00AM +, Matt Caswell wrote:
>> OpenSSL 3.0 has recently been designated as a Long Term Support (LTS)
>> release. This means that it will now be supported until 7th September
>> 2026 (5 years after its initial release).
>> 
>> Our previous LTS release (1.1.1) will continue to be supported until
>> 11th September 2023.
>> 
>> We encourage all users to upgrade to 3.0.
>> 
> 
> 
> Though I full agree, what is Apple's stand on gettng their clients upgraded
> to openssl3 compilance?
> 
>> Yours,
>> The OpenSSL Project Team
> 
> 
> 
> 
> 
> 
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> Look at Psalms 14 and 53 on Atheism 
> https://urldefense.com/v3/__https://www.empire.kred/ROOTNK?t=94a1f39b__;!!GjvTz_vk!D9V7BUjD7_WYZb-MFNIM1B5vPCGGhjFNF3Bh8w6c_691AQgafZRZJZmvQfcb$
> Siding with murders against the innocent is progress only to fools. -unknown 
> Beware 
> https://urldefense.com/v3/__https://mindspring.com__;!!GjvTz_vk!D9V7BUjD7_WYZb-MFNIM1B5vPCGGhjFNF3Bh8w6c_691AQgafZRZJRTcE69B$



signature.asc
Description: Message signed with OpenPGP

Re: OpenSSL 3.0 LTS

[The Doctor via openssl-users]

On Fri, Mar 04, 2022 at 11:04:00AM +, Matt Caswell wrote:
> OpenSSL 3.0 has recently been designated as a Long Term Support (LTS) 
> release. This means that it will now be supported until 7th September 
> 2026 (5 years after its initial release).
> 
> Our previous LTS release (1.1.1) will continue to be supported until 
> 11th September 2023.
> 
> We encourage all users to upgrade to 3.0.
>


Though I full agree, what is Apple's stand on gettng their clients upgraded
to openssl3 compilance?

> Yours,
> The OpenSSL Project Team






-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
Siding with murders against the innocent is progress only to fools. -unknown 
Beware https://mindspring.com

Re: OpenSSL 3.0 FIPS module configuration file

[Richard Dymond]

On Tue, 15 Feb 2022 at 09:53, Tomas Mraz  wrote:

> Please note that there are two checksums in the configuration file. One
> of them is the FIPS module checksum and the other is the checksum of
> the configuration. You can copy the file across machines if it is
> without the configuration checksum - that means the selftest will be
> always run when the FIPS module (i.e., the fips provider) is loaded.
>

Thanks for the info! I was wondering whether there was a FIPS-compliant way
to use fips.dll on a machine without first having to run 'openssl
fipsinstall' on that machine, and this seems to be it.

Richard

Re: OpenSSL 3.0 FIPS module configuration file

[Tomas Mraz]

Please note that there are two checksums in the configuration file. One
of them is the FIPS module checksum and the other is the checksum of
the configuration. You can copy the file across machines if it is
without the configuration checksum - that means the selftest will be
always run when the FIPS module (i.e., the fips provider) is loaded. 

You cannot copy the file if the configuration checksum is present in it
though because that means the selftest won't be run on the machines
where you copy the configuration file to. That would be against the
FIPS implementation guidance that requires to run the selftests at
least once after the installation.

Tomas

On Tue, 2022-02-15 at 10:31 +1100, 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
>  
>  

-- 
Tomáš Mráz, OpenSSL

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

[Thomas Dwyer III]

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

[Ma Ar]

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]

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 support

[Tomas Mraz]

Yeah, you need to add the @SECLEVEL=0 in the cipher string to set the
security level to 0. That is needed to allow SHA1 in signatures which
is required for these TLS versions.

Tomas Mraz


On Thu, 2022-02-03 at 17:36 +1100, pa...@openssl.org wrote:
>  It does support both.  I think a configuration time option might be
> required and neither is supported by the FIPS provider.
>  
>  Paul Dale
>  
>  
> On 3/2/22 4:32 pm, Srinivas, Saketh (c) wrote:
>  
> >   
> >  Hi,
> >  
> >  Does openssl 3.0 still support TLSv 1.0 and TLSv1.1. or they are
> > deprecated, because there were some deprecations like sha1 etc.
> >  
> >  Thanks,
> >  Saketh.
> >  
> >  
> >  
> >  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.
>  
>  

-- 
Tomáš Mráz, OpenSSL

Re: Openssl 3.0 support

[pauli]

It does support both.  I think a configuration time option might be 
required and neither is supported by the FIPS provider.


Paul Dale


On 3/2/22 4:32 pm, Srinivas, Saketh (c) wrote:

Hi,

Does openssl 3.0 still support TLSv 1.0 and TLSv1.1. or they are 
deprecated, because there were some deprecations like sha1 etc.


Thanks,
Saketh.



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: OpenSSL 3.0 password prompt errors

[pepone.onrez]

Tested on a separate machine (Ubuntu Jammy Jellyfish) that comes with
OpenSSL 3.x installed and things worked as expected.

Probably something was screwed with my own build or the machine that has
several OpenSSL versions.

Thanks for the help, and sorry for the inconvenience.

Cheers,
Jose

On Tue, 30 Nov 2021 at 15:09, Matt Caswell  wrote:

>
>
> On 30/11/2021 13:16, pepone.onrez wrote:
> > Getting some problems with OpenSSL 3.0, I have passwordError function,
> > to check if the last error was due to an invalid password and allow the
> > user to retry.
> >
> >
> > bool
> > passwordError()
> > {
> >  unsigned long error = ERR_peek_error();
> >  unsigned long lib = ERR_GET_LIB(error);
> >  unsigned long reason = ERR_GET_REASON(error);
> >  cerr << "error: " << error << endl;
> >  cerr << "lib: " << lib << endl;
> >  cerr << "reason: " << reason << endl;
> >  ERR_print_errors_fp(stdout);
> >  return (reason == PEM_R_BAD_BASE64_DECODE ||
> >  reason == PEM_R_BAD_DECRYPT ||
> >  reason == PEM_R_BAD_PASSWORD_READ ||
> >  reason == PEM_R_PROBLEMS_GETTING_PASSWORD ||
> >  reason == PKCS12_R_MAC_VERIFY_FAILURE);
> > }
> >
> > When I test with an invalid password I get
> >
> > error: 587686001
> > lib: 70
> > reason: 483441
> > error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure
>
> That is really screwy output. Something is getting corrupted somewhere.
> "70" is not a valid error library and a reason code of 483441 is clearly
> wrong (reason codes are typically fairly small). Error 587686001 does
> correspond to the hex value 23076071 - but this is not an error value I
> would expect to see OpenSSL emitting.
>
> Could there be memory corruption occurring?? Perhaps run this through
> valgrind or similar and see if there are any hints.
>
> Matt
>
>
>
> >
> >
> > the description seems to match PKCS12_R_MAC_VERIFY_FAILURE but the
> > reason value doesn't
> >
> > include/openssl/pkcs12err.h
> > 39:# define PKCS12_R_MAC_VERIFY_FAILURE  113
> >
> > Any ideas what I might be doing wrong here? this worked fine with 1.1.1
> > before
> >
> > Cheers,
> > Jose
>

Re: OpenSSL 3.0 password prompt errors

[Matt Caswell]

On 30/11/2021 13:16, pepone.onrez wrote:
Getting some problems with OpenSSL 3.0, I have passwordError function, 
to check if the last error was due to an invalid password and allow the 
user to retry.



bool
passwordError()
{
     unsigned long error = ERR_peek_error();
     unsigned long lib = ERR_GET_LIB(error);
     unsigned long reason = ERR_GET_REASON(error);
     cerr << "error: " << error << endl;
     cerr << "lib: " << lib << endl;
     cerr << "reason: " << reason << endl;
     ERR_print_errors_fp(stdout);
     return (reason == PEM_R_BAD_BASE64_DECODE ||
             reason == PEM_R_BAD_DECRYPT ||
             reason == PEM_R_BAD_PASSWORD_READ ||
             reason == PEM_R_PROBLEMS_GETTING_PASSWORD ||
             reason == PKCS12_R_MAC_VERIFY_FAILURE);
}

When I test with an invalid password I get

error: 587686001
lib: 70
reason: 483441
error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure


That is really screwy output. Something is getting corrupted somewhere. 
"70" is not a valid error library and a reason code of 483441 is clearly 
wrong (reason codes are typically fairly small). Error 587686001 does 
correspond to the hex value 23076071 - but this is not an error value I 
would expect to see OpenSSL emitting.


Could there be memory corruption occurring?? Perhaps run this through 
valgrind or similar and see if there are any hints.


Matt






the description seems to match PKCS12_R_MAC_VERIFY_FAILURE but the 
reason value doesn't


include/openssl/pkcs12err.h
39:# define PKCS12_R_MAC_VERIFY_FAILURE                      113

Any ideas what I might be doing wrong here? this worked fine with 1.1.1 
before


Cheers,
Jose

RE: Openssl 3.0 fipsinstall fails in yocto linux environment

[Susan Tremel]

Hi Kory,

I am cross-compiling. Here is the command line from the "perl configdta.pm
--dump" command. I'm using an existing openssl 3. 0 recipe which I just
modified with enable-fips.

perl ../openssl-3.0.0/Configure disable-devcryptoeng enable-fips
--prefix=/usr --openssldir=/usr/lib/ssl-3 --libdir=/usr/lib linux-armv4

The output of openssl version -a is as follows.

OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)
built on: Tue Sep  7 11:46:32 2021 UTC
platform: linux-armv4
options:  bn(64,32)
compiler: arm-poky-linux-gnueabi-gcc  -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a7 -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security --sysroot=recipe-sysroot -O2 -pipe
-g -feliminate-unused-debug-types -fmacro-prefix-map=
-fdebug-prefix-map=  -fdebug-prefix-map=
-fdebug-prefix-map=  -DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSL_BUILDING_OPENSSL -DNDEBUG
OPENSSLDIR: "/usr/lib/ssl-3"
ENGINESDIR: "/usr/lib/engines-3"
MODULESDIR: "/usr/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_armcap=0x1

thanks,
Susan



Message: 2
Date: Tue, 9 Nov 2021 14:32:19 -0800
From: Kory Hamzeh 
To: openssl-users@openssl.org
Subject: Re: Openssl 3.0 fipsinstall fails in yocto linux environment
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Hi Susan,

How did you run Configure? Are you cross compiling?

Be default, OpenSSL 3.0.0 builds for /usr/local. Your MUST install it there
or use a Configure option if you want to install it somewhere else.

Kory


> On Nov 9, 2021, at 2:21 PM, Susan Tremel 
wrote:
> 
> I?ve successfully built and installed openssl 3.0 and the fips.so module
in my yocto build environment. My goal is to make the FIPs module the
default provider for all applications so I modified my openssl.cnf file  to
match the docs like the following.
>  
> config_diagnostics = 1
> openssl_conf = openssl_init
>  
> .include /usr/lib/ssl-3/fipsmodule.cnf
>  
> [openssl_init]
> providers = provider_sect
>  
> [provider_sect]
> fips = fips_sect
> base = base_sect
>  
> [base_sect]
> activate = 1
>  
> After boot, I check the installed providers with ?openssl list ?providers?
and see only the base provider. I then try to install the FIPS module with
the following.
>  
> openssl fipsinstall ?module /usr/lib/ossl-modules/fips.so ?out
/usr/lib/ssl-3/fipsmodule.cnf 
>  
> and I get the error output:
> Unable to get MAC of type HMAC
> INSTALL FAILED
> 1020F876:error:0308010C:digital envelope
routines:inner_evp_generic_fetch:unsupported:../openssl-3.0.0/crypto/evp/evp
_fetch.c:346:Global default library context, Algorithm (HMAC : 0),
Properties ()
>  
> When I replace the base provider with the default provider, leaving the
fips module like the following
>  
> config_diagnostics = 1
> openssl_conf = openssl_init
>  
> .include /usr/lib/ssl-3/fipsmodule.cnf
>  
> [openssl_init]
> providers = provider_sect
>  
> [provider_sect]
> default = default_sect
> fips = fips_sect
>  
> [default_sect]
> activate = 1
>  
> I see only the default provider installed after I boot and when I try to
manually install the FIPS module with the above command I get the following.
> Failed to load FIPS module
> INSTALL FAILED
> 1080F176:error:1C8000D4:Provider routines:SELF_TEST_post:invalid
state:../openssl-3.0.0/providers/fips/self_test.c:261:
> 1080F176:error:1C8000D8:Provider routines:OSSL_provider_init_int:self test
post failure:../openssl-3.0.0/providers/fips/fipsprov.c:706:
> 1080F176:error:078C0105:common libcrypto routines:provider_init:init
fail:../openssl-3.0.0/crypto/provider_core.c:903:name=fips
>  
> From this state, if I copy the ossl-modules directory to a different
location like /usr/lib/ssl-3/ and try to manually install the FIPS module
with
>  
> openssl fipsinstall ?module /usr/lib/ssl-3/ossl-modules/fips.so ?out
/usr/lib/ssl-3/fipsmodule.cnf 
>  
> it successful installs with the following output and I see both the fips
and default providers installed.
> 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
> AES_ECB_Decrypt : (KAT_Cipher) : Pass
> RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass
> Pass
> ECDSA : (PCT_Signature) : Pass
> ECDSA : (PCT_Signature) : Pass
> DSA : (PCT_Signature) : Pass
> TLS13_KDF_EXTRACT : (KAT_KDF) : Pass
> TLS13_KDF_EXPAND : (KAT_KDF) : Pass
> TLS12_PRF : (KAT_KDF) : Pass
> PBKDF2 : (KAT_KDF) : Pass
> SSHKDF : (KAT_KDF) : Pass
> KBKDF : (KAT_KDF) : Pass
> H

Re: Openssl 3.0 fipsinstall fails in yocto linux environment

[Kory Hamzeh]

Hi Susan,

How did you run Configure? Are you cross compiling?

Be default, OpenSSL 3.0.0 builds for /usr/local. Your MUST install it there or 
use a Configure option if you want to install it somewhere else.

Kory


> On Nov 9, 2021, at 2:21 PM, Susan Tremel  wrote:
> 
> I’ve successfully built and installed openssl 3.0 and the fips.so module in 
> my yocto build environment. My goal is to make the FIPs module the default 
> provider for all applications so I modified my openssl.cnf file  to match the 
> docs like the following.
>  
> config_diagnostics = 1
> openssl_conf = openssl_init
>  
> .include /usr/lib/ssl-3/fipsmodule.cnf
>  
> [openssl_init]
> providers = provider_sect
>  
> [provider_sect]
> fips = fips_sect
> base = base_sect
>  
> [base_sect]
> activate = 1
>  
> After boot, I check the installed providers with “openssl list –providers” 
> and see only the base provider. I then try to install the FIPS module with 
> the following.
>  
> openssl fipsinstall –module /usr/lib/ossl-modules/fips.so –out 
> /usr/lib/ssl-3/fipsmodule.cnf 
>  
> and I get the error output:
> Unable to get MAC of type HMAC
> INSTALL FAILED
> 1020F876:error:0308010C:digital envelope 
> routines:inner_evp_generic_fetch:unsupported:../openssl-3.0.0/crypto/evp/evp_fetch.c:346:Global
>  default library context, Algorithm (HMAC : 0), Properties ()
>  
> When I replace the base provider with the default provider, leaving the fips 
> module like the following
>  
> config_diagnostics = 1
> openssl_conf = openssl_init
>  
> .include /usr/lib/ssl-3/fipsmodule.cnf
>  
> [openssl_init]
> providers = provider_sect
>  
> [provider_sect]
> default = default_sect
> fips = fips_sect
>  
> [default_sect]
> activate = 1
>  
> I see only the default provider installed after I boot and when I try to 
> manually install the FIPS module with the above command I get the following.
> Failed to load FIPS module
> INSTALL FAILED
> 1080F176:error:1C8000D4:Provider routines:SELF_TEST_post:invalid 
> state:../openssl-3.0.0/providers/fips/self_test.c:261:
> 1080F176:error:1C8000D8:Provider routines:OSSL_provider_init_int:self test 
> post failure:../openssl-3.0.0/providers/fips/fipsprov.c:706:
> 1080F176:error:078C0105:common libcrypto routines:provider_init:init 
> fail:../openssl-3.0.0/crypto/provider_core.c:903:name=fips
>  
> From this state, if I copy the ossl-modules directory to a different location 
> like /usr/lib/ssl-3/ and try to manually install the FIPS module with
>  
> openssl fipsinstall –module /usr/lib/ssl-3/ossl-modules/fips.so –out 
> /usr/lib/ssl-3/fipsmodule.cnf 
>  
> it successful installs with the following output and I see both the fips and 
> default providers installed.
> 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
> AES_ECB_Decrypt : (KAT_Cipher) : Pass
> RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass
> Pass
> ECDSA : (PCT_Signature) : Pass
> ECDSA : (PCT_Signature) : Pass
> DSA : (PCT_Signature) : Pass
> TLS13_KDF_EXTRACT : (KAT_KDF) : Pass
> TLS13_KDF_EXPAND : (KAT_KDF) : 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
>  
> I need to get the FIPS module to install without needing the default 
> provider. It seems like the FIPS module is trying to install and getting 
> stuck in a bad state, but I could use some help debugging this.
>  
> Thanks for any help you can provide.
> Susan

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks to everyone for the help so far. I think I have things set up correctly 
as far as FIPS, providers, and library contexts. I'm hitting another problem 
that I think is related to the migration to OpenSSL 3.0, as this code works 
with OpenSSL 1.1.1 (and 1.0.2 before it). When looking at the documentation 
pages for 1.1.1 vs 3.0, I'm not seeing any differences between the OpenSSL APIs 
I'm calling in the 2 different release levels.

Here is the sequence, I'm basically setting up my certificate and private key, 
both in PEM format, for the server, then I need to extract some information 
from them:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
fp = fopen(, "r");
mycert = PEM_read_X509(fp, NULL, 0, NULL);
pkey = X509_get_pubkey(mycert);

All functions return good statuses or non-NULL pointers until the last one, 
X509_get_pubkey() returns NULL. I have tried this with RSA and Elliptic Curve 
cert/key pairs. I have tried with pairs created with OpenSSL 1.1.1 as well as 
3.0 via the command line.

This seems like a pretty straightforward operation, but it appears that 
key->pkey is NULL in the code below:

EVP_PKEY *X509_PUBKEY_get0(const X509_PUBKEY *key)
{
if (key == NULL) {
ERR_raise(ERR_LIB_X509, ERR_R_PASSED_NULL_PARAMETER);
return NULL;
}

if (key->pkey == NULL) {
/* We failed to decode the key when we loaded it, or it was never set */
ERR_raise(ERR_LIB_EVP, EVP_R_DECODE_ERROR);
return NULL;
}

return key->pkey;
}

I got to this code from the error information I dumped from OpenSSL:

00079FF8647F:error:0372:digital envelope routines:(unknown 
function):decode error:crypto/x509/x_pubkey.c:444:

I can paste certificates if anyone thinks it will help, but I've tried several 
types of cert/key pairs, and using the command line to do "openssl x509 
-pubkey..." displays the public key just fine with the certificate file in 
question.

Here is an example of the openssl command line to create one of the cert/key 
pairs that hits this error:

openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) 
-keyout threecert.key -out threecert.crt -days 365

I kept this on the same "FIPS OpenSSL 3.0" thread because I'm not 100% sure 
it's unrelated.

What am I missing here?

Thanks,

Jason



From: Matt Caswell 
Sent: Thursday, October 28, 2021 6:03 PM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 28/10/2021 18:33, Jason Schultz wrote:
> Thanks Matt. I think I have what I need as far as loading providers. I
> also did the test you suggested with EVP_MD_fetch() and things failed as
> expected, the fetch did not work.
>
> One other question on providers, given how I load everything, it seems
> like before application exit, the cleanup should be the following:
>
>  OSSL_LIB_CTX_free(fips_libctx);
>  OSSL_LIB_CTX_free(non_fips_libctx);
>  OSSL_PROVIDER_unload(defp);

Yes, but I would recommend unloading the default provider before freeing
the libctx it is associated with. Otherwise bad things might happen.

>
> Since I didn't "explicitly" load the fips and base providers with API
> calls, I only need to unlead the default provider, as well as free both
> library contexts.

Correct.

>
> Also, when I did try to unload the fips and base providers, the call to
> OSSL_PROVIDER_unload() hung, with the following backtrace:

Yeah. Don't do that. :-)

Matt

>
> #1  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from
> /lib64/libcrypto.so.3
> #2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from
> /lib64/libcrypto.so.3
> #3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
> #4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
> #5  0x7fb37f51b813 in ossl_provider_deactivate () from
> /lib64/libcrypto.so.3
> #6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3
>
> Thanks,
>
> Jason
>
>
> ------------
> *From:* Matt Caswell 
> *Sent:* Thursday, October 28, 2021 2:00 PM
> *To:* Jason Schultz ; Dr Paul Dale
> ; openssl-users@openssl.org 
> *Subject:* Re: OpenSSL 3.0 FIPS questions
>
>
> On 28/10/2021 14:49, Jason Schultz wrote:
>> A call to OSSL_PROVIDER_available() says the "default" provider is
>> available;  however, I'm wondering if I should be loading the default
>> provider via *load_config() as well? I would have to uncomment the
>> "activate = 1" in the defa

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

On 28/10/2021 18:33, Jason Schultz wrote:
Thanks Matt. I think I have what I need as far as loading providers. I 
also did the test you suggested with EVP_MD_fetch() and things failed as 
expected, the fetch did not work.


One other question on providers, given how I load everything, it seems 
like before application exit, the cleanup should be the following:


     OSSL_LIB_CTX_free(fips_libctx);
     OSSL_LIB_CTX_free(non_fips_libctx);
     OSSL_PROVIDER_unload(defp);


Yes, but I would recommend unloading the default provider before freeing 
the libctx it is associated with. Otherwise bad things might happen.




Since I didn't "explicitly" load the fips and base providers with API 
calls, I only need to unlead the default provider, as well as free both 
library contexts.


Correct.



Also, when I did try to unload the fips and base providers, the call to 
OSSL_PROVIDER_unload() hung, with the following backtrace:


Yeah. Don't do that. :-)

Matt



#1  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from 
/lib64/libcrypto.so.3
#2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from 
/lib64/libcrypto.so.3

#3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
#4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
#5  0x7fb37f51b813 in ossl_provider_deactivate () from 
/lib64/libcrypto.so.3

#6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3

Thanks,

Jason



*From:* Matt Caswell 
*Sent:* Thursday, October 28, 2021 2:00 PM
*To:* Jason Schultz ; Dr Paul Dale 
; openssl-users@openssl.org 

*Subject:* Re: OpenSSL 3.0 FIPS questions


On 28/10/2021 14:49, Jason Schultz wrote:
A call to OSSL_PROVIDER_available() says the "default" provider is 
available;  however, I'm wondering if I should be loading the default 
provider via *load_config() as well? I would have to uncomment the 
"activate = 1" in the default section of my config though.


This is entirely a matter of personal taste. It makes no difference
functionally whether you load a provider via OSSL_PROVIDER_load()
directly, or whether you do it via the config file. Obviously if you do
it via a config file it gives you the ability to modify what providers
get loaded later without having to recompile.

If you decided to do it via config then you probably want *2* different
config files. One for the fips libctx and one for the non-fips libctx.




I also still have this in my code:

      /* Disallow falling back to the default library context */
      nullp = OSSL_PROVIDER_load(NULL, "null");

But not sure it's having any affect?


You could attempt to test it by attempting to fetch an algorithm. We
would expect it to fail if it is working as expected. E.g.

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
if (md != NULL) {
  /* Should not happen! The null provider should prevent this */
}




I do know that later in my application, both in "FIPS" or "non-FIPS" 
mode, I can  create an SSL_CTX with SSL_CTX_new_ex(). I also 
successfully call several APIs using both the fips_libctx or the 
non_fips_libctx, for example:


status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_check_private_key(ctx);


All return successfully. So I think what I have between configuration 
files and API calls accomplishes what I need to. Would anyone reading 
this agree?


It sounds correct from what you have described.

Matt



I'm running into another issue that I need to troubleshoot a bit more 
before I add too much information and too many questions to a single 
message.


Thanks to everyone for their help with this, things are starting to make 
more sense now.





*From:* Matt Caswell 
*Sent:* Thursday, October 28, 2021 7:39 AM
*To:* Jason Schultz ; Dr Paul Dale 
; openssl-users@openssl.org 

*Subject:* Re: OpenSSL 3.0 FIPS questions


On 27/10/2021 17:28, Jason Schultz wrote:
With these config files and the code above, the 
OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the 
messages from the ERR_print_errors_fp() call:


2097C692B57F:error:1C8000D5:Provider routines:(unknown 
function):missing config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown 
function):fips module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown 
function):self test post failure:providers/fips/fipsprov.c:706:
2097C692B57F:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:903:name=fips



This tells us that the fips provider has successfully loaded, but then
subsequently failed during its self-test bec

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks Matt. I think I have what I need as far as loading providers. I also did 
the test you suggested with EVP_MD_fetch() and things failed as expected, the 
fetch did not work.

One other question on providers, given how I load everything, it seems like 
before application exit, the cleanup should be the following:

OSSL_LIB_CTX_free(fips_libctx);
OSSL_LIB_CTX_free(non_fips_libctx);
OSSL_PROVIDER_unload(defp);

Since I didn't "explicitly" load the fips and base providers with API calls, I 
only need to unlead the default provider, as well as free both library contexts.

Also, when I did try to unload the fips and base providers, the call to 
OSSL_PROVIDER_unload() hung, with the following backtrace:

#1  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from /lib64/libcrypto.so.3
#2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from /lib64/libcrypto.so.3
#3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
#4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
#5  0x7fb37f51b813 in ossl_provider_deactivate () from /lib64/libcrypto.so.3
#6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3

Thanks,

Jason



From: Matt Caswell 
Sent: Thursday, October 28, 2021 2:00 PM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 28/10/2021 14:49, Jason Schultz wrote:
> A call to OSSL_PROVIDER_available() says the "default" provider is
> available;  however, I'm wondering if I should be loading the default
> provider via *load_config() as well? I would have to uncomment the
> "activate = 1" in the default section of my config though.

This is entirely a matter of personal taste. It makes no difference
functionally whether you load a provider via OSSL_PROVIDER_load()
directly, or whether you do it via the config file. Obviously if you do
it via a config file it gives you the ability to modify what providers
get loaded later without having to recompile.

If you decided to do it via config then you probably want *2* different
config files. One for the fips libctx and one for the non-fips libctx.


>
> I also still have this in my code:
>
>  /* Disallow falling back to the default library context */
>  nullp = OSSL_PROVIDER_load(NULL, "null");
>
> But not sure it's having any affect?

You could attempt to test it by attempting to fetch an algorithm. We
would expect it to fail if it is working as expected. E.g.

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
if (md != NULL) {
 /* Should not happen! The null provider should prevent this */
}


>
> I do know that later in my application, both in "FIPS" or "non-FIPS"
> mode, I can  create an SSL_CTX with SSL_CTX_new_ex(). I also
> successfully call several APIs using both the fips_libctx or the
> non_fips_libctx, for example:
>
> status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
>
> status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
>
> status = SSL_CTX_check_private_key(ctx);
>
>
> All return successfully. So I think what I have between configuration
> files and API calls accomplishes what I need to. Would anyone reading
> this agree?

It sounds correct from what you have described.

Matt

>
> I'm running into another issue that I need to troubleshoot a bit more
> before I add too much information and too many questions to a single
> message.
>
> Thanks to everyone for their help with this, things are starting to make
> more sense now.
>
>
>
> ----------------
> *From:* Matt Caswell 
> *Sent:* Thursday, October 28, 2021 7:39 AM
> *To:* Jason Schultz ; Dr Paul Dale
> ; openssl-users@openssl.org 
> *Subject:* Re: OpenSSL 3.0 FIPS questions
>
>
> On 27/10/2021 17:28, Jason Schultz wrote:
>> With these config files and the code above, the
>> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the
>> messages from the ERR_print_errors_fp() call:
>>
>> 2097C692B57F:error:1C8000D5:Provider routines:(unknown
>> function):missing config data:providers/fips/self_test.c:289:
>> 2097C692B57F:error:1C8000E0:Provider routines:(unknown
>> function):fips module entering error state:providers/fips/self_test.c:387:
>> 2097C692B57F:error:1C8000D8:Provider routines:(unknown
>> function):self test post failure:providers/fips/fipsprov.c:706:
>> 2097C692B57F:error:078C0105:common libcrypto routines:(unknown
>> function):init fail:crypto/provider_core.c:903:name=fips
>
>
> This tells us that the fips provider has successfully loaded, but then
> subsequently failed during its self-test becaus

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

On 28/10/2021 14:49, Jason Schultz wrote:
A call to OSSL_PROVIDER_available() says the "default" provider is 
available;  however, I'm wondering if I should be loading the default 
provider via *load_config() as well? I would have to uncomment the 
"activate = 1" in the default section of my config though.


This is entirely a matter of personal taste. It makes no difference 
functionally whether you load a provider via OSSL_PROVIDER_load() 
directly, or whether you do it via the config file. Obviously if you do 
it via a config file it gives you the ability to modify what providers 
get loaded later without having to recompile.


If you decided to do it via config then you probably want *2* different 
config files. One for the fips libctx and one for the non-fips libctx.





I also still have this in my code:

     /* Disallow falling back to the default library context */
     nullp = OSSL_PROVIDER_load(NULL, "null");

But not sure it's having any affect?


You could attempt to test it by attempting to fetch an algorithm. We 
would expect it to fail if it is working as expected. E.g.


EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
if (md != NULL) {
/* Should not happen! The null provider should prevent this */
}




I do know that later in my application, both in "FIPS" or "non-FIPS" 
mode, I can  create an SSL_CTX with SSL_CTX_new_ex(). I also 
successfully call several APIs using both the fips_libctx or the 
non_fips_libctx, for example:


status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_check_private_key(ctx);


All return successfully. So I think what I have between configuration 
files and API calls accomplishes what I need to. Would anyone reading 
this agree?


It sounds correct from what you have described.

Matt



I'm running into another issue that I need to troubleshoot a bit more 
before I add too much information and too many questions to a single 
message.


Thanks to everyone for their help with this, things are starting to make 
more sense now.





*From:* Matt Caswell 
*Sent:* Thursday, October 28, 2021 7:39 AM
*To:* Jason Schultz ; Dr Paul Dale 
; openssl-users@openssl.org 

*Subject:* Re: OpenSSL 3.0 FIPS questions


On 27/10/2021 17:28, Jason Schultz wrote:
With these config files and the code above, the 
OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the 
messages from the ERR_print_errors_fp() call:


2097C692B57F:error:1C8000D5:Provider routines:(unknown 
function):missing config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown 
function):fips module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown 
function):self test post failure:providers/fips/fipsprov.c:706:
2097C692B57F:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:903:name=fips



This tells us that the fips provider has successfully loaded, but then
subsequently failed during its self-test because it cannot find its
config data.

I can see that you have created a separate libctx for fips. However
automatic loading of the config file only works for the *default*
libctx. If you create your own one then you need to explicitly load the
config file:

if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) {
  /* error handling */
}

Actually if you do this then you should not need to call
OSSL_PROVIDER_load() explicitly to load the fips provider since you
already activated it in the config file. You can either drop the
explicit call to OSSL_PROVIDER_load() for the fips provider, or remove
the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a
minor optimisation though. Doing both is redundant but harmless. You
could also load the base provider via config if you wanted to.

Matt

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks Matt. I actually had this working (loading the fips_libctx using the 
*load_config() API) but I was hitting other issues and thought I was doing 
something wrong (more on that later).

So to review, I have my own config file, /usr/local/ssl/openssl-fips, with the 
relevant contents(some comments snipped):

.include /usr/local/ssl/fipsmodule.cnf

[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
base = base_sect

[default_sect]
# activate = 1

[base_sect]
activate = 1

And then fipsmodule.cnf contains:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

By activating the fips and base providers via config, my application then calls:

OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf");

Which loads the "fips" and "base" providers in the fips_libctx, which I verify 
with:

OSSL_PROVIDER_available(fips_libctx, "fips");
and
OSSL_PROVIDER_available(fips_libctx, "base")

...and both are available.

However, remember I am trying to create two non-default library contexts (from 
earlier code):

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

Again, I think I have what I need for the fibs_libctx. For the non_fips_libctx, 
I'm calling:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
nullp = OSSL_PROVIDER_load(NULL, "null");

A call to OSSL_PROVIDER_available() says the "default" provider is available;  
however, I'm wondering if I should be loading the default provider via 
*load_config() as well? I would have to uncomment the "activate = 1" in the 
default section of my config though.

I also still have this in my code:

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");

But not sure it's having any affect?

I do know that later in my application, both in "FIPS" or "non-FIPS" mode, I 
can  create an SSL_CTX with SSL_CTX_new_ex(). I also successfully call several 
APIs using both the fips_libctx or the non_fips_libctx, for example:


status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_check_private_key(ctx);

All return successfully. So I think what I have between configuration files and 
API calls accomplishes what I need to. Would anyone reading this agree?

I'm running into another issue that I need to troubleshoot a bit more before I 
add too much information and too many questions to a single message.

Thanks to everyone for their help with this, things are starting to make more 
sense now.



________
From: Matt Caswell 
Sent: Thursday, October 28, 2021 7:39 AM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 27/10/2021 17:28, Jason Schultz wrote:
> With these config files and the code above, the
> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the
> messages from the ERR_print_errors_fp() call:
>
> 2097C692B57F:error:1C8000D5:Provider routines:(unknown
> function):missing config data:providers/fips/self_test.c:289:
> 2097C692B57F:error:1C8000E0:Provider routines:(unknown
> function):fips module entering error state:providers/fips/self_test.c:387:
> 2097C692B57F:error:1C8000D8:Provider routines:(unknown
> function):self test post failure:providers/fips/fipsprov.c:706:
> 2097C692B57F:error:078C0105:common libcrypto routines:(unknown
> function):init fail:crypto/provider_core.c:903:name=fips


This tells us that the fips provider has successfully loaded, but then
subsequently failed during its self-test because it cannot find its
config data.

I can see that you have created a separate libctx for fips. However
automatic loading of the config file only works for the *default*
libctx. If you create your own one then you need to explicitly load the
config file:

if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) {
 /* error handling */
}

Actually if you do this then you should not need to call
OSSL_PROVIDER_load() explicitly to load the fips provider since you
already activated it in the config file. You can either drop the
explicit call to OSSL_PROVIDER_load() for the fips provider, or remove
the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a
minor optimisation though. Doing both is redundant but harmless. You
could also load the base provider via config if you wanted to.

Matt

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

On 27/10/2021 17:28, Jason Schultz wrote:
With these config files and the code above, the 
OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the 
messages from the ERR_print_errors_fp() call:


2097C692B57F:error:1C8000D5:Provider routines:(unknown 
function):missing config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown 
function):fips module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown 
function):self test post failure:providers/fips/fipsprov.c:706:
2097C692B57F:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:903:name=fips



This tells us that the fips provider has successfully loaded, but then 
subsequently failed during its self-test because it cannot find its 
config data.


I can see that you have created a separate libctx for fips. However 
automatic loading of the config file only works for the *default* 
libctx. If you create your own one then you need to explicitly load the 
config file:


if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) {
/* error handling */
}

Actually if you do this then you should not need to call 
OSSL_PROVIDER_load() explicitly to load the fips provider since you 
already activated it in the config file. You can either drop the 
explicit call to OSSL_PROVIDER_load() for the fips provider, or remove 
the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a 
minor optimisation though. Doing both is redundant but harmless. You 
could also load the base provider via config if you wanted to.


Matt

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Sorry, I meant to include the config information in my previous email. I should 
probably go back to the beginning, I've been trying a lot of different 
combinations without success, so unwinding to the beginning and taking one step 
at a time is probably appropriate. Since I want the FIPS changes limited to my 
application only, this is based on the response from Dr. Paul Dale earlier in 
the thread, the first approach he recommended, so the application code looks 
like this:

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
// error handling
 }

basep = OSSL_PROVIDER_load(fips_libctx, "base"); /* can't load keys without 
this */
if (basep == NULL)
  {
/* error handling */
   }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */

  }

Since I'm back to not using my own config file, this is the relevant content in 
/usr/local/ssl/openssl.cnf. Again, from Dr. Paul Dale's advice of needing a 
FIPS section, and not needing base or default sections:

openssl_conf = openssl_init

.include /usr/local/ssl/fipsmodule.cnf

[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

[default_sect]
# activate = 1

Here is the /usr/local/ssl/fipsmodule.cnf file:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

With these config files and the code above, the OSSL_PROVIDER_load(fips_libctx, 
"fips") call fails. Here are the messages from the ERR_print_errors_fp() call:

2097C692B57F:error:1C8000D5:Provider routines:(unknown function):missing 
config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown function):fips 
module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown function):self test 
post failure:providers/fips/fipsprov.c:706:
2097C692B57F:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:903:name=fips

So this does seem like I have something wrong as far as setup/install or 
configuration. I'm not sure if it's something in the config files above, or 
something with my application being able to find the fips.so, which was also 
mentioned. The code above in self_test.c that's throwing the error looks like 
the st parameter to SELF_TESET_post() is NULL, but I'm not sure what the actual 
problem is. The self test isn't set up to run correctly, the self test failed, 
maybe both, or maybe something else?

One of the links from Matt included a function  
OSSL_PROVIDER_set_default_search_path(). I'm wondering if that's needed since I 
don't have any environment variables set up? I'm not sure what the default 
search path is.

Jason



From: Matt Caswell 
Sent: Wednesday, October 27, 2021 10:34 AM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 26/10/2021 20:17, Jason Schultz wrote:
> Thanks for all of the help so far. Unfortunately, I'm still struggling
> with this. There could be a number of issues, starting with the
> installation of OpenSSL. I basically followed the documentation and did
> the following:
>
> ./Configure enable-fips
>
> make
>
> make test
>
> make install
>
>
> The "make test" actually fails, but I did not troubleshoot as it seems
> like a lot of systems have issues here. But I know the .so produced when
> I build my application is linking to the correct OpenSSL libraries
> (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0.
>
> I've tried a number of combinations trying to make this work, starting
> with the code from Dr. Paul Dale in a previous message:
>
>  fips_libctx = OSSL_LIB_CTX_new();
>  if (!fips_libctx)
>  // error handling
>
>  non_fips_libctx = OSSL_LIB_CTX_new();
>  if (!non_fips_libctx)
>  // error handling
>
>  fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
>  if (fipsp == NULL)
>{
>  /* error handling */
>}
>
>  basep = OSSL_PROVIDER_load(fips_libctx, "base");
>  if (basep == NULL)
>{
>  /* error handling */
>}
>
>  defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
>  if (defp == NULL)
>{
>  /* error handling */
>}
>
>  /* Disallow falling back to the d

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

On 26/10/2021 20:17, Jason Schultz wrote:
Thanks for all of the help so far. Unfortunately, I'm still struggling 
with this. There could be a number of issues, starting with the 
installation of OpenSSL. I basically followed the documentation and did 
the following:


./Configure enable-fips

make

make test

make install


The "make test" actually fails, but I did not troubleshoot as it seems 
like a lot of systems have issues here. But I know the .so produced when 
I build my application is linking to the correct OpenSSL libraries 
(libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0.


I've tried a number of combinations trying to make this work, starting 
with the code from Dr. Paul Dale in a previous message:


     fips_libctx = OSSL_LIB_CTX_new();
     if (!fips_libctx)
         // error handling

     non_fips_libctx = OSSL_LIB_CTX_new();
     if (!non_fips_libctx)
         // error handling

     fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
     if (fipsp == NULL)
       {
         /* error handling */
       }

     basep = OSSL_PROVIDER_load(fips_libctx, "base");
     if (basep == NULL)
       {
         /* error handling */
       }

     defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
     if (defp == NULL)
       {
         /* error handling */
       }

     /* Disallow falling back to the default library context */
     nullp = OSSL_PROVIDER_load(NULL, "null");
     if (nullp == NULL)
       {
         /*error handling */
       }

With the code like the above, the OSSL_PROVIDER_load() calls fails for 
fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and 
returns NULL, which is probably expected given the fips provider didn't 
load.


At that point, I wasn't sure if my application was using the (correct) 
config file in /usr/local/ssl/. I don't have any environment variables 
set up, and would prefer not to have to set any to get this to work. So 
I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config():


     if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))


What is in the /usr/local/ssl/openssl-fips.cnf config file?

Does the config file attempt to activate the FIPS provider itself? Does 
it supply the necessary FIPS provider config parameters?


Typically the config file has a ".include" directive in it which 
includes the necessary FIPS config params. That included file will look 
something like this:


$ cat fipsmodule.cnf

[fips_sect]

activate = 1

conditional-errors = 1

security-checks = 1

module-mac = 
95:06:06:D1:85:17:92:F6:7B:7D:C2:43:36:A4:59:5D:75:6F:39:E6:13:0B:4B:26:5A:1B:48:78:33:5B:BE:F0


Most likely what is happening is that the FIPS provider is failing to 
load. Either because it cannot find the fips.so file, or because the 
necessary FIPS config parameters above are not found or not correct.


You can test whether a provider is actually available for use or not 
using the OSSL_PROVIDER_available() function call. E.g.:


if (!OSSL_PROVIDER_available(fips_libctx, "fips")) {
/* error handling */
}

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

If things are failing then you might find it helpful to dump the OpenSSL 
error stack to try and get some clues as to what the problem might be, e.g.


ERR_print_errors_fp(stdout);

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

Matt

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Ah, OK. Yes, I am running on the same machine. Thanks for clarifying.



From: Kory Hamzeh 
Sent: Tuesday, October 26, 2021 9:15 PM
To: Jason Schultz 
Cc: Dr Paul Dale ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

Actually, if you are running on the same machine that you built OpenSSL, you 
are fine. I cross-compile and have to do a fipsinstall each time. My apologies.


On Oct 26, 2021, at 12:17 PM, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:

./Configure enable-fips
make
make test
make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale mailto:pa...@openssl.org>>
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL 3.0 FIPS questions

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 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specify

Re: OpenSSL 3.0 FIPS questions

[Kory Hamzeh]

Actually, if you are running on the same machine that you built OpenSSL, you 
are fine. I cross-compile and have to do a fipsinstall each time. My apologies.


> On Oct 26, 2021, at 12:17 PM, Jason Schultz  wrote:
> 
> Thanks for all of the help so far. Unfortunately, I'm still struggling with 
> this. There could be a number of issues, starting with the installation of 
> OpenSSL. I basically followed the documentation and did the following:
> 
> ./Configure enable-fips
> make
> make test
> make install
> 
> The "make test" actually fails, but I did not troubleshoot as it seems like a 
> lot of systems have issues here. But I know the .so produced when I build my 
> application is linking to the correct OpenSSL libraries (libssl.so.3 and 
> libcrypto.so.3). Checking the OpenSSL version shows 3.0.
> 
> I've tried a number of combinations trying to make this work, starting with 
> the code from Dr. Paul Dale in a previous message:
> 
> fips_libctx = OSSL_LIB_CTX_new();
> if (!fips_libctx)
> // error handling
> 
> non_fips_libctx = OSSL_LIB_CTX_new();
> if (!non_fips_libctx)
> // error handling
> 
> fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
> if (fipsp == NULL)
>   {
> /* error handling */
>   }
> 
> 
> basep = OSSL_PROVIDER_load(fips_libctx, "base"); 
> if (basep == NULL)
>   {
> /* error handling */
>   }
> 
> defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
> if (defp == NULL)
>   {
> /* error handling */
>   }
> 
> /* Disallow falling back to the default library context */
> 
> nullp = OSSL_PROVIDER_load(NULL, "null");
> if (nullp == NULL)
>   {
> /*error handling */
>   }
> 
> With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. 
> If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns 
> NULL, which is probably expected given the fips provider didn't load.
> 
> At that point, I wasn't sure if my application was using the (correct) config 
> file in /usr/local/ssl/. I don't have any environment variables set up, and 
> would prefer not to have to set any to get this to work. So I changed the 
> provider load for FIPS to use OSSL_LIB_CTX_load_config():
> 
> if (!OSSL_LIB_CTX_load_config(fips_libctx, 
> "/usr/local/ssl/openssl-fips.cnf"))
>   // error handling
> 
> This seems to work load the provider; however, there are two separate 
> problems at this point. If FIPS is enabled by my application creating the 
> SSL_CTX with  the FIPS library context fails, returning NULL. 
> 
> If FIPS is turned OFF by my application, creating an SSL_CTX with the 
> non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
> NULL, implying maybe something is wrong with the non_fips_libctx as well. 
> 
> I've tried other combinations, but at this point I'm just guessing. Is there 
> anything obvious I could be missing and I should be checking?
> 
> Thanks,
> 
> Jason
> 
> 
> From: Dr Paul Dale 
> Sent: Monday, October 25, 2021 9:37 PM
> To: Jason Schultz ; openssl-users@openssl.org 
> 
> Subject: Re: OpenSSL 3.0 FIPS questions
>  
> 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  
>> <mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale 
>>  <mailto:pa...@openssl.org>
>> Sent: Sunday, October 24, 2021 11:12 PM
>> To: openssl-users@openssl.org <mailto:openssl-users@opens

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Kory-

If I'm understanding the README-FIPS.md file, I don't need to do the 
"fipsinstall", it is done during the normal installation process when FIPS is 
enabled, presumably with the "enable-fips" on the configure command:

Installing the FIPS module
==

If the FIPS provider is enabled, it gets installed automatically during the
normal installation process. Simply follow the normal procedure (configure,
make, make test, make install) as described in the [INSTALL](INSTALL.md) file.

For example, on Unix the final command

$ make install

effectively executes the following install targets

$ make install_sw
$ make install_ssldirs
$ make install_docs
$ make install_fips # for `enable-fips` only

It looks like the fips.so shared object was produced from these steps on my 
system, in /usr/local/lib64/ossl-modules/.

Are you saying I still needed to do "openssl fipsinstall" after the 4 steps I 
already did?

Thanks,

Jason



From: Kory Hamzeh 
Sent: Tuesday, October 26, 2021 8:13 PM
To: Jason Schultz 
Cc: Dr Paul Dale ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

Did you follow the steps in README-FIPS.md and do the “fipsinstall”?


On Oct 26, 2021, at 12:17 PM, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:

./Configure enable-fips
make
make test
make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale mailto:pa...@openssl.org>>
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL 3.0 FIPS questions

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 OS

Re: OpenSSL 3.0 FIPS questions

[Kory Hamzeh]

Did you follow the steps in README-FIPS.md and do the “fipsinstall”?


> On Oct 26, 2021, at 12:17 PM, Jason Schultz  wrote:
> 
> Thanks for all of the help so far. Unfortunately, I'm still struggling with 
> this. There could be a number of issues, starting with the installation of 
> OpenSSL. I basically followed the documentation and did the following:
> 
> ./Configure enable-fips
> make
> make test
> make install
> 
> The "make test" actually fails, but I did not troubleshoot as it seems like a 
> lot of systems have issues here. But I know the .so produced when I build my 
> application is linking to the correct OpenSSL libraries (libssl.so.3 and 
> libcrypto.so.3). Checking the OpenSSL version shows 3.0.
> 
> I've tried a number of combinations trying to make this work, starting with 
> the code from Dr. Paul Dale in a previous message:
> 
> fips_libctx = OSSL_LIB_CTX_new();
> if (!fips_libctx)
> // error handling
> 
> non_fips_libctx = OSSL_LIB_CTX_new();
> if (!non_fips_libctx)
> // error handling
> 
> fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
> if (fipsp == NULL)
>   {
> /* error handling */
>   }
> 
> 
> basep = OSSL_PROVIDER_load(fips_libctx, "base"); 
> if (basep == NULL)
>   {
> /* error handling */
>   }
> 
> defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
> if (defp == NULL)
>   {
> /* error handling */
>   }
> 
> /* Disallow falling back to the default library context */
> 
> nullp = OSSL_PROVIDER_load(NULL, "null");
> if (nullp == NULL)
>   {
> /*error handling */
>   }
> 
> With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. 
> If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns 
> NULL, which is probably expected given the fips provider didn't load.
> 
> At that point, I wasn't sure if my application was using the (correct) config 
> file in /usr/local/ssl/. I don't have any environment variables set up, and 
> would prefer not to have to set any to get this to work. So I changed the 
> provider load for FIPS to use OSSL_LIB_CTX_load_config():
> 
> if (!OSSL_LIB_CTX_load_config(fips_libctx, 
> "/usr/local/ssl/openssl-fips.cnf"))
>   // error handling
> 
> This seems to work load the provider; however, there are two separate 
> problems at this point. If FIPS is enabled by my application creating the 
> SSL_CTX with  the FIPS library context fails, returning NULL. 
> 
> If FIPS is turned OFF by my application, creating an SSL_CTX with the 
> non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
> NULL, implying maybe something is wrong with the non_fips_libctx as well. 
> 
> I've tried other combinations, but at this point I'm just guessing. Is there 
> anything obvious I could be missing and I should be checking?
> 
> Thanks,
> 
> Jason
> 
> 
> From: Dr Paul Dale 
> Sent: Monday, October 25, 2021 9:37 PM
> To: Jason Schultz ; openssl-users@openssl.org 
> 
> Subject: Re: OpenSSL 3.0 FIPS questions
>  
> 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  
>> <mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale 
>>  <mailto:pa...@openssl.org>
>> Sent: Sunday, October 24, 2021 11:12 PM
>> To: openssl-users@openssl.org <mailto:openssl-users@openssl.org> 
>>  <mailto:openssl-users@openssl.org>
>> Subject: Re: O

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:


./Configure enable-fips

make

make test

make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale 
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

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 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto: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: Su

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

[Jason Schultz]

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

[Jason Schultz]

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 sur

Re: OpenSSL 3.0 FIPS questions

[Kory Hamzeh]

One way to do what you want is with two config file, and and in the first line 
of your main() function, add:

putenv(“OPENSSL_CONF=/path/to/your/conf”)

depending on whether you want to run in FIPS mode or not. Of course, this only 
works if FIPS is needed application wide, not on a per connection basis.

If running in FIPS mode, I would also call:

EVP_set_default_properties(NULL, “fips=yes”);


> On Oct 23, 2021, at 9: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: 
>  
> A non-default library context with the FIPS provider loaded (called 
> fips_libctx), and 
> 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 sure the 
> default provider was activated. 
>  
> I also changed the fipsmodule.cnf file to comment out the activate = 1 line: 
>  
> [fips_sect] 
> # activate = 1 
> conditional-errors = 1 
> security-checks = 1 
> module-mac = 
> E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9
>  
>  
> That was from the “Programmatically loading 

Re: openssl 3.0 - id2_x509() now fails

[Tomas Mraz]

On Mon, 2021-08-09 at 09:48 -0400, Ken Goldman wrote:
> On 8/9/2021 3:50 AM, Tomas Mraz wrote:
> > On Fri, 2021-08-06 at 18:06 -0400, Ken Goldman wrote:
> > > On 8/6/2021 1:11 PM, Ken Goldman wrote:
> > > > I have an application where I have to create a partial x509
> > > > certificate.  It gets sent to an HSM, which fills in the public
> > > > key
> > > > and signs it.
> > > > 
> > > > I was calling
> > > > 
> > > >   X509_new
> > > >   X509_set_version
> > > >   X509_set_issuer_name
> > > >   X509_get_notBefore
> > > >   X509_get_notAfter
> > > >   X509_set_subject_name
> > > >   X509_EXTENSION_create_by_OBJ
> > > > 
> > > > and then
> > > >   i2d_x509
> > > > to send the serialized partial certificate to the HSM.
> > > > 
> > > > This worked in 1.0.1, 1.0.2, 1.1.1, but fails in 3.0.0.
> > > > 
> > > > In debugging, even this fails.
> > > > 
> > > >   X509_new
> > > >   i2d_x509
> > > > 
> > > > Suggestions?
> > > 
> > > Following up, I found that just omitting the signature from the
> > > X509 structure causes i2d_x509 to fail.
> > > 
> > > I tried i2d_re_X509_tbs(), but it also failed.
> > 
> > I am afraid with the current 3.0 codebase there are not many
> > options
> > how to workaround apart from either signing the certificate with a
> > bogus key - if the HSM is able to re-sign such certificate.
> 
> My hope is that the maintainers will revert this change.  Perhaps
> they can write a new variant of i2d_x509 that requires the full
> certificate rather than change the existing API.
> 
> The i2d__re_x509_tbs() API seems promising (tbs is 'to be signed'),
> but it apparently is strict on what data must be there.
> 
> The HSM (TPM, ISO 11889) cannot change.  It expects a
> partial certificate.  It's API is already defined.
> 
> > Another (more complicated) option would be to define your own ASN.1
> > X509 structure where the signature would be optional and thus the
> > stricter encoder that is now in 3.0 codebase would allow encoding
> > the
> > incomplete certificate.
> 
> If you can post some hints on how to do this, I'll try it.
> 
> My alternative is to write the asn1 code from scratch, but I know
> how fragile that will be.

Why would you write asn1 code from scratch when OpenSSL has all the
APIs needed to create any ASN.1 structure.

Look at the crypto/x509/x_x509.c and make the signature optional. Of
course you would not be able to use the X509_set/get functions and
would have to also copy the X509_CINF definition. Which makes the
workaround quite complicated anyway.

-- 
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: openssl 3.0 - id2_x509() now fails

[Ken Goldman]

On 8/9/2021 3:50 AM, Tomas Mraz wrote:

On Fri, 2021-08-06 at 18:06 -0400, Ken Goldman wrote:

On 8/6/2021 1:11 PM, Ken Goldman wrote:

I have an application where I have to create a partial x509
certificate.  It gets sent to an HSM, which fills in the public key
and signs it.

I was calling

  X509_new
  X509_set_version
  X509_set_issuer_name
  X509_get_notBefore
  X509_get_notAfter
  X509_set_subject_name
  X509_EXTENSION_create_by_OBJ

and then
  i2d_x509
to send the serialized partial certificate to the HSM.

This worked in 1.0.1, 1.0.2, 1.1.1, but fails in 3.0.0.

In debugging, even this fails.

  X509_new
  i2d_x509

Suggestions?


Following up, I found that just omitting the signature from the
X509 structure causes i2d_x509 to fail.

I tried i2d_re_X509_tbs(), but it also failed.


I am afraid with the current 3.0 codebase there are not many options
how to workaround apart from either signing the certificate with a
bogus key - if the HSM is able to re-sign such certificate.


My hope is that the maintainers will revert this change.  Perhaps
they can write a new variant of i2d_x509 that requires the full
certificate rather than change the existing API.

The i2d__re_x509_tbs() API seems promising (tbs is 'to be signed'),
but it apparently is strict on what data must be there.

The HSM (TPM, ISO 11889) cannot change.  It expects a
partial certificate.  It's API is already defined.


Another (more complicated) option would be to define your own ASN.1
X509 structure where the signature would be optional and thus the
stricter encoder that is now in 3.0 codebase would allow encoding the
incomplete certificate.


If you can post some hints on how to do this, I'll try it.

My alternative is to write the asn1 code from scratch, but I know
how fragile that will be.

Re: openssl 3.0 - id2_x509() now fails

[Tomas Mraz]

On Fri, 2021-08-06 at 18:06 -0400, Ken Goldman wrote:
> On 8/6/2021 1:11 PM, Ken Goldman wrote:
> > I have an application where I have to create a partial x509
> > certificate.  It gets sent to an HSM, which fills in the public key
> > and signs it.
> > 
> > I was calling
> > 
> >  X509_new
> >  X509_set_version
> >  X509_set_issuer_name
> >  X509_get_notBefore
> >  X509_get_notAfter
> >  X509_set_subject_name
> >  X509_EXTENSION_create_by_OBJ
> > 
> > and then
> >  i2d_x509
> > to send the serialized partial certificate to the HSM.
> > 
> > This worked in 1.0.1, 1.0.2, 1.1.1, but fails in 3.0.0.
> > 
> > In debugging, even this fails.
> > 
> >  X509_new
> >  i2d_x509
> > 
> > Suggestions?
> 
> Following up, I found that just omitting the signature from the
> X509 structure causes i2d_x509 to fail.
> 
> I tried i2d_re_X509_tbs(), but it also failed.

I am afraid with the current 3.0 codebase there are not many options
how to workaround apart from either signing the certificate with a
bogus key - if the HSM is able to re-sign such certificate.

Another (more complicated) option would be to define your own ASN.1
X509 structure where the signature would be optional and thus the
stricter encoder that is now in 3.0 codebase would allow encoding the
incomplete certificate.

-- 
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: openssl 3.0 - id2_x509() now fails

[Ken Goldman]

On 8/6/2021 1:11 PM, Ken Goldman wrote:

I have an application where I have to create a partial x509 certificate.  It 
gets sent to an HSM, which fills in the public key and signs it.

I was calling

 X509_new
 X509_set_version
 X509_set_issuer_name
 X509_get_notBefore
 X509_get_notAfter
 X509_set_subject_name
 X509_EXTENSION_create_by_OBJ

and then
 i2d_x509
to send the serialized partial certificate to the HSM.

This worked in 1.0.1, 1.0.2, 1.1.1, but fails in 3.0.0.

In debugging, even this fails.

 X509_new
 i2d_x509

Suggestions?


Following up, I found that just omitting the signature from the
X509 structure causes i2d_x509 to fail.

I tried i2d_re_X509_tbs(), but it also failed.

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 3.0 beta versus actual

[Matt Caswell]

On 25/06/2021 08:01, Sandeep Umesh wrote:

Hello
While the beta version has been released now, please let us know if 
there is any timeline to release the actual 3.0 version ?
What changes are expected to be 3.0 version compared to its beta ? it is 
restricted to bug-fixes only ?


We are expecting 3.0 actual to be released in Q3 of this year.

Beta is bug fixes only - no new features.

Matt

Re: OpenSSL 3.0 - providing entropy to EVP_RAND ?

[Bala Duvvuri via openssl-users]

 Thank you for all the help, got this working.

Thanks
Bala
 On Thursday, 15 April, 2021, 04:02:10 am IST, Dr Paul Dale 
 wrote:  
 
  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 = &drbg_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 
 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 se

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 = &drbg_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 
  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

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: OpenSSL 3.0 - providing entropy to EVP_RAND ?

[Bala Duvvuri via openssl-users]

 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: 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: OpenSSL 3.0 daily snapshot

[The Doctor]

On Mon, Feb 15, 2021 at 02:06:17PM +0100, Richard Levitte wrote:
> Hmmm, I have never seen that (apart from in one of my own development 
> branches, but that never reached the main source).
> 
> If you want anyone to look into it, it would be a good idea to show us what 
> your configuration is. The output from this command is recommended:
> 
> perl configdata.pm -d
> 
> Cheers
> Richard
> 
> 
> The Doctor  skrev: (14 februari 2021 13:33:51 CET)
> >Anyome running tests running into an infinite loop 
> >on 04-test_encoder_decoder_legacy.t ?
>

Will do.


Command line (with current working directory = .):

/usr/local/bin/perl ./Configure --prefix=/usr/local/ BSD-x86_64 
enable-ec_nistp_64_gcc_128 enable-sctp enable-fips no-crypto-mdebug 
no-crypto-mdebug-backtrace no-asan no-fuzz-afl no-fuzz-libfuzzer no-heartbeats 
no-idea no-md2 no-md4 no-msan no-rc5 no-sm2 no-sm3 enable-rfc3779 enable-shared 
zlib-dynamic enable-rc4 no-ssl3 no-ssl3-method no-ubsan no-weak-ssl-ciphers 
no-idea enable-ssl-trace enable-unit-test

Perl information:

/usr/local/bin/perl
5.30.3 for amd64-freebsd-thread-multi

Enabled features:

acvp_tests
aria
asm
async
autoalginit
autoerrinit
autoload-config
bf
blake2
bulk
cached-fetch
camellia
capieng
cast
chacha
cmac
cmp
cms
comp
ct
deprecated
des
devcryptoeng
dgram
dh
dsa
dso
dtls
dynamic-engine
ec
ec2m
ecdh
ecdsa
ec_nistp_64_gcc_128
engine
err
filenames
fips
fips-securitychecks
gost
legacy
makedepend
mdc2
module
multiblock
nextprotoneg
pinshared
ocb
ocsp
padlockeng
pic
poly1305
posix-io
psk
rc2
rc4
rdrand
rfc3779
rmd160
scrypt
sctp
secure-memory
seed
shared
siphash
siv
sm4
sock
srp
srtp
sse2
ssl
ssl-trace
static-engine
stdio
tests
threads
tls
ts
ui-console
unit-test
whirlpool
zlib
zlib-dynamic
tls1
tls1-method
tls1_1
tls1_1-method
tls1_2
tls1_2-method
tls1_3
dtls1
dtls1-method
dtls1_2
dtls1_2-method

Disabled features:

afalgeng[not-linux]   OPENSSL_NO_AFALGENG
asan[option]  OPENSSL_NO_ASAN
buildtest-c++   [default] 
crypto-mdebug   [option]  OPENSSL_NO_CRYPTO_MDEBUG
egd [default] OPENSSL_NO_EGD
external-tests  [default] OPENSSL_NO_EXTERNAL_TESTS
fuzz-libfuzzer  [option]  OPENSSL_NO_FUZZ_LIBFUZZER
fuzz-afl[option]  OPENSSL_NO_FUZZ_AFL
idea[option]  OPENSSL_NO_IDEA (skip crypto/idea)
ktls[default] OPENSSL_NO_KTLS
md2 [option]  OPENSSL_NO_MD2 (skip crypto/md2)
md4 [option]  OPENSSL_NO_MD4 (skip crypto/md4)
msan[option]  OPENSSL_NO_MSAN
rc5 [option]  OPENSSL_NO_RC5 (skip crypto/rc5)
sm2 [option]  OPENSSL_NO_SM2 (skip crypto/sm2)
sm3 [option]  OPENSSL_NO_SM3 (skip crypto/sm3)
trace   [default] OPENSSL_NO_TRACE
ubsan   [option]  OPENSSL_NO_UBSAN
uplink  [no uplink_arch]  OPENSSL_NO_UPLINK
weak-ssl-ciphers[option]  OPENSSL_NO_WEAK_SSL_CIPHERS
ssl3[option(ssl3-method)] OPENSSL_NO_SSL3
ssl3-method [option]  OPENSSL_NO_SSL3_METHOD

Config target attributes:

AR => "ar",
ARFLAGS => "qc",
CC => "cc",
CFLAGS => "-Wall -O3",
HASHBANGPERL => "/usr/bin/env perl",
RANLIB => "ranlib",
RC => "windres",
asm_arch => "x86_64",
bn_ops => "SIXTY_FOUR_BIT_LONG",
build_file => "Makefile",
build_scheme => [ "unified", "unix" ],
cflags => "-pthread",
cppflags => "-D_THREAD_SAFE -D_REENTRANT",
defines => [ "OPENSSL_BUILDING_OPENSSL", "ZLIB", "ZLIB_SHARED" ],
disable => [  ],
dso_ldflags => "-Wl,-z,defs",
dso_scheme => "dlfcn",
enable => [ "devcryptoeng" ],
ex_libs => "-pthread",
includes => [  ],
lflags => "",
lib_cflags => "",
lib_cppflags => "-DL_ENDIAN",
lib_defines => [  ],
module_cflags => "-fPIC",
module_cxxflags => undef,
module_ldflags => "-shared -Wl,-Bsymbolic",
perl_platform => "Unix",
perlasm_scheme => "elf",
shared_cflag => "-fPIC",
shared_defflag => "-Wl,--version-script=",
shared_defines => [  ],
shared_ldflag => "-shared -Wl,-Bsymbolic",
shared_rcflag => "",
shared_sonameflag => "-Wl,-soname=",
shared_target => "bsd-gcc-shared",
thread_defines => [  ],
thread_scheme => "pthreads",
 

Re: OpenSSL 3.0 daily snapshot

[Richard Levitte]

Hmmm, I have never seen that (apart from in one of my own development branches, 
but that never reached the main source).

If you want anyone to look into it, it would be a good idea to show us what 
your configuration is. The output from this command is recommended:

perl configdata.pm -d

Cheers
Richard


The Doctor  skrev: (14 februari 2021 13:33:51 CET)
>Anyome running tests running into an infinite loop 
>on 04-test_encoder_decoder_legacy.t ?

-- 
Richard by mobile

Re: OPenssl 3.0 issues

[Richard Levitte]

That should be fixed, I merged a fixup commit yesterday.

Cheers,
Richard

On Mon, 25 Jan 2021 15:56:28 +0100,
The Doctor wrote:
> 
> Anyone using BSD running into basename issues?
> 
> -- 
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
>  
> Born 29 Jan 1969 Redhill, Surrey, UK 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OPenssl 3.0 issues

[John Baldwin]

On 1/25/21 6:56 AM, The Doctor wrote:

Anyone using BSD running into basename issues?
 
I have not, but my use of 3.0 has been limited to KTLS testing

with nginx.  Are you referring to whether or not the string
returned by basename(3) is part of the input string or whether
it is a copy stored in an internal buffer in libc?

--
John Baldwin

Re: OPenssl 3.0 issues

[Blumenthal, Uri - 0553 - MITLL]

On 1/25/21, 10:13, "openssl-users on behalf of The Doctor" 
 wrote:

Anyone using BSD running into basename issues?

Basename issues on MacOS. Presumably the same as you're having on BSD.
 


smime.p7s
Description: S/MIME cryptographic signature

Re: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Thomas Dwyer III]

I just created https://github.com/openssl/openssl/issues/12496 for this.


Regards,
Tom.III


On Sat, Jul 18, 2020 at 1:06 AM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> Thomas,
>
>
>
> > I consider this a bug, of course, but at least now I know what's causing
> it and how to work around it.
>
>
>
> thanks for sharing your analysis. Would you mind creating a GitHub issue
> for the hang?
>
>
>
> https://github.com/openssl/openssl/issues
>
>
>
> Matthias
>
>
>
>
>
>
>
> *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre*
>
> Senior Software Engineer
> matthias.st.pie...@ncp-e.com
> Phone: +49 911 9968-0
> www.ncp-e.com
>
>
> * Follow us on:* Facebook <https://www.facebook.com/NCPengineering> |
> Twitter <https://twitter.com/NCP_engineering> | Xing
> <https://www.xing.com/companies/ncpengineeringgmbh> | YouTube
> <https://www.youtube.com/user/NCPengineeringGmbH> | LinkedIn
> <http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>
>
> *Headquarters Germany: *NCP engineering GmbH • Dombuehler Str. 2 • 90449
> • Nuremberg
> *North American HQ:* NCP engineering Inc. • 601 Cleveland Str., Suite
> 501-25 • Clearwater, FL 33755
>
> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate
> Dietrich
> Registry Court: Lower District Court of Nuremberg
> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE
> 133557619
>
> This e-mail message including any attachments is for the sole use of the
> intended recipient(s) and may contain privileged or confidential
> information. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please immediately
> contact the sender by reply e-mail and delete the original message and
> destroy all copies thereof.
>
> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen>
> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen>
>
> *From:* openssl-users  *On Behalf Of 
> *Thomas
> Dwyer III
> *Sent:* Friday, July 17, 2020 6:57 PM
> *To:* openssl-users 
> *Subject:* [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider
>
>
>
> It turns out the problem was caused by a misinterpretation of the phrase
> "add the following lines near the beginning" in section 7.1 of the
> documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for
> enabling FIPS support. I added these lines to the very top of the file:
>
>
>
> openssl_conf = openssl_init
>
>
>
> .include /usr/local/ssl/fipsmodule.cnf
>
>
>
> [openssl_init]
>
> providers = provider_sect
>
>
>
> [provider_sect]
>
> fips = fips_sect
>
>
>
> This caused the existing default section to now become part of the
> [provider_sect] section. Apparently any name=value line in that particular
> section where no [value] section exists causes OpenSSL to hang at exit when
> the FIPS provider is used. I consider this a bug, of course, but at least
> now I know what's causing it and how to work around it.
>
>
>
> Regarding how to confirm which provider is actually providing a given
> algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD
> obtained via EVP_get_digestbyname() (even after it's used successfully by
> EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD
> obtained via EVP_MD_fetch(). Is this intentional?
>
>
>
>
>
> Tom.III
>
>
>

Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Matt Caswell]

On 15/07/2020 18:20, Thomas Dwyer III wrote:
> Platform: Linux x86_64
> 
> I understand this is still alpha but how complete is the FIPS provider
> right now? 

Fairly complete.

Please could you raise this as a github issue so that it can be properly
investigated and tracked?

> When I run this it prints "finished!" and then hangs in some kind of
> spin loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex()
> allows it to exit successfully, as does inserting a call to
> OPENSSL_init_crypto() at the very top with the OPENSSL_INIT_NO_ATEXIT
> flag. Passing "default" instead of "fips" to OSSL_PROVIDER_load() also
> seems to work fine. What am I missing?
> 
> Also, per section 7.8 of the wiki referenced above, I'm unable to
> confirm that the digest algorithm I want to use is being provided by the
> FIPS module. EVP_MD_provider(md) returns NULL even though the actual
> digest is computed correctly.

You need to explicitly fetch your md using EVP_MD_fetch(). The md you
are using at the moment has no associated provider - one is implicitly
fetched and used during the EVP_DigestInit_ex() call - but that doesn't
affect the md object. By using "EVP_MD_fetch()" you can make the fetch
explicit and EVP_MD_provider() should return the expected results.

Matt


> 
> 
> Thanks,
> Tom.III
> 
> 

RE: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Dr. Matthias St. Pierre]

Thomas,

> I consider this a bug, of course, but at least now I know what's causing it 
> and how to work around it.

thanks for sharing your analysis. Would you mind creating a GitHub issue for 
the hang?

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

Matthias


From: openssl-users  On Behalf Of Thomas 
Dwyer III
Sent: Friday, July 17, 2020 6:57 PM
To: openssl-users 
Subject: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

It turns out the problem was caused by a misinterpretation of the phrase "add 
the following lines near the beginning" in section 7.1 of the documentation at 
https://wiki.openssl.org/index.php/OpenSSL_3.0 for enabling FIPS support. I 
added these lines to the very top of the file:


openssl_conf = openssl_init



.include /usr/local/ssl/fipsmodule.cnf



[openssl_init]

providers = provider_sect



[provider_sect]

fips = fips_sect

This caused the existing default section to now become part of the 
[provider_sect] section. Apparently any name=value line in that particular 
section where no [value] section exists causes OpenSSL to hang at exit when the 
FIPS provider is used. I consider this a bug, of course, but at least now I 
know what's causing it and how to work around it.

Regarding how to confirm which provider is actually providing a given 
algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD obtained 
via EVP_get_digestbyname() (even after it's used successfully by 
EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD 
obtained via EVP_MD_fetch(). Is this intentional?


Tom.III

[SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Thomas Dwyer III]

It turns out the problem was caused by a misinterpretation of the phrase
"add the following lines near the beginning" in section 7.1 of the
documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for
enabling FIPS support. I added these lines to the very top of the file:

openssl_conf = openssl_init

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

[provider_sect]
fips = fips_sect


This caused the existing default section to now become part of the
[provider_sect] section. Apparently any name=value line in that particular
section where no [value] section exists causes OpenSSL to hang at exit when
the FIPS provider is used. I consider this a bug, of course, but at least
now I know what's causing it and how to work around it.

Regarding how to confirm which provider is actually providing a given
algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD
obtained via EVP_get_digestbyname() (even after it's used successfully by
EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD
obtained via EVP_MD_fetch(). Is this intentional?


Tom.III


On Wed, Jul 15, 2020 at 10:20 AM Thomas Dwyer III  wrote:

> Platform: Linux x86_64
>
> I understand this is still alpha but how complete is the FIPS provider
> right now? I'm following the documentation at
> https://wiki.openssl.org/index.php/OpenSSL_3.0 but I'm having a problem
> where my application hangs during exit() when I use the "fips" provider. I
> reduced my code down to this minimal snippet that reproduces the problem:
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int
> main(int argc, char **argv)
> {
> OSSL_PROVIDER *pvdr = NULL;
> EVP_MD_CTX *ctx;
> const EVP_MD *md;
> char *alg = "sha1";
> int rc = 0;
>
> pvdr = OSSL_PROVIDER_load(NULL, "fips");
> if (pvdr == NULL) {
> fprintf(stderr, "Error loading FIPS provider\n");
> exit(1);
> }
>
> md = EVP_get_digestbyname(alg);
> if (!md) {
> fprintf(stderr, "unknown digest '%s'\n", alg);
> exit(1);
> }
>
> ctx = EVP_MD_CTX_create();
>
> if (EVP_DigestInit_ex(ctx, md, NULL) != 1) {
> long err = ERR_get_error();
> char *msg = ERR_error_string(err, NULL);
> fprintf(stderr, "EVP_DigestInit_ex() failed: %s\n", msg);
> exit(1);
> }
>
> EVP_MD_CTX_destroy(ctx);
>
> rc = OSSL_PROVIDER_unload(pvdr);
> if (rc != 1) {
> fprintf(stderr, "Error unloading FIPS provider\n");
> exit(1);
> }
>
> printf("finished!\n");
> exit(0);
> }
>
> When I run this it prints "finished!" and then hangs in some kind of spin
> loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex() allows it
> to exit successfully, as does inserting a call to OPENSSL_init_crypto() at
> the very top with the OPENSSL_INIT_NO_ATEXIT flag. Passing "default"
> instead of "fips" to OSSL_PROVIDER_load() also seems to work fine. What am
> I missing?
>
> Also, per section 7.8 of the wiki referenced above, I'm unable to confirm
> that the digest algorithm I want to use is being provided by the FIPS
> module. EVP_MD_provider(md) returns NULL even though the actual digest is
> computed correctly.
>
>
> Thanks,
> Tom.III
>
>
>

Re: OpenSSL 3.0

[Matt Caswell]

On 27/02/2020 20:37, Jason Schultz wrote:
> Thanks for all of the responses. This question has led to other related
> topics, so I have another one. According to this blog:
> 
> https://keypair.us/2019/12/rip-fips-186-2/
> 
> The OpenSSL FIPS Object Module will be moved to the CMVP historical list
> as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS
> Module will be after that sometime, where does this leave 1.0.2 users
> who need a FIPS validated object module past that date? 

Going to the historic list will not impact existing deployments at all.
If you already have the old module deployed you can continue to use it,
even if it is on the historic list as I understand it.

You will not be able to make *new* deployments if it goes historic.

The problem is with FIPS 186-2 RSA Key gen. Modules now need to be FIPS
186-4 compliant. But the OpenSSL FIPS Object Module 2.0 is not 186-4 and
will not updated to be so. One option is to update the validation to
remove RSA as an approved algorithm (this can be done as a purely
paperwork exercise). But doing that has implications for existing
deployments. The OMC discussed this some months ago but decided not to
take any action at that time. I'm sure it will be discussed again next
time we have a f2f.

Matt



> 
> 
> 
> 
> *From:* openssl-users  on behalf of
> Salz, Rich via openssl-users 
> *Sent:* Thursday, February 27, 2020 1:31 PM
> *To:* Matt Caswell ; openssl-users@openssl.org
> 
> *Subject:* Re: OpenSSL 3.0
>  
> 
>>    It would probably be a good idea for us to pull together a "Getting
>     Started" guide on the Wiki with some basic information on how to get
>     things going, with some links to the various man pages etc where more
>     detailed information is required.
>  
> This needs to be real user documentation as part of the FIPS
> deliverable, right?
> 

Re: OpenSSL 3.0

[Walter Paley]

To clarify an important distinction - SafeLogic Extended Support for 1.0.2 
architecture will not keep the OpenSSL FOM validated past 9/1/2020. SafeLogic 
does offer a compatible drop-in replacement module that is validated, will 
remain validated past the 186-2 deprecation on 9/1/2020, and is available with 
RapidCert, an accelerated validation in your company’s name, but that is a 
separate offering.

- Walt



Walter Paley
w...@safelogic.com

> On Feb 27, 2020, at 12:59 PM, openssl-users-requ...@openssl.org wrote:
> 
> 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
> 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 3.0 (Salz, Rich)
>   2. Re: OpenSSL 3.0 (Neptune)
>   3. Re: OpenSSL 3.0 (Salz, Rich)
>   4. Re: OpenSSL 3.0 (Jason Schultz)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 27 Feb 2020 20:49:33 +
> From: "Salz, Rich" 
> To: Jason Schultz , "openssl-users@openssl.org"
>
> Subject: Re: OpenSSL 3.0
> Message-ID: <1e825139-40c4-4888-ab96-32fc423f0...@akamai.com>
> Content-Type: text/plain; charset="utf-8"
> 
>  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
> as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS 
> Module will be after that sometime, where does this leave 1.0.2 users who 
> need a FIPS validated object module past that date?
> 
> Without their free lunch?
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mta.openssl.org/pipermail/openssl-users/attachments/20200227/6e69ca80/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Thu, 27 Feb 2020 13:56:10 -0700 (MST)
> From: Neptune 
> To: openssl-users@openssl.org
> Subject: Re: OpenSSL 3.0
> Message-ID: <1582836970178-0.p...@n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> You essentially have three choices:
> 1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
> year without support or security patches.
> 2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
> to receive patches on 1.0.2 for the remainder of the year.
> 3. Pay SafeLogic for support contract to receive 1.0.2 security patches
> through the year. Cost is roughly half what OpenSSL is asking, but you may
> be able to negotiate.
> 
> These are the only options of which I am aware.
> 
> 
> 
> 
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> 
> 
> --
> 
> Message: 3
> Date: Thu, 27 Feb 2020 20:58:10 +
> From: "Salz, Rich" 
> To: Jason Schultz , "openssl-users@openssl.org"
>
> Subject: Re: OpenSSL 3.0
> Message-ID: <3cfef9fc-d5e7-46d4-8d61-c485bf81e...@akamai.com>
> Content-Type: text/plain; charset="utf-8"
> 
>  *   That's fair. So the only option is to use another module? Extended 1.0.2 
> support does not resolve this either, correct?
> 
> I do not think that is the only option.  For example, you might be able to 
> use 3.0 and say it?s ?in evaluation.? There might be other options, that was 
> all I could think of while composing this email.
> 
> HOWEVER, note that the set of validated platforms for 3.0 is very different 
> from the current FOM.  Someone officially with the project will have to 
> provide details on that, not me.
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mta.openssl.org/pipermail/openssl-users/attachments/20200227/985830ee/attachment-0001.html>
> 
> --
> 
> Message: 4
> Date: Thu, 27 Feb 2020 20:58:36 +
> From: Jason Schultz 
> To: "openssl-users@openssl.org" 
> Subject: Re: OpenSSL 3.0
> Message-ID:
>
> 
>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> For option 2, we have a support contract in place. But does this actually 
> help us as far as the FIPS Object Module?
> 
> 
> 
> From: openssl-users  on behalf of Neptune 
> 
> Sent: Thursday, February 27,

Re: OpenSSL 3.0

[Jason Schultz]

That's fair. So the only option is to use another module? Extended 1.0.2 
support does not resolve this either, correct?


From: Salz, Rich 
Sent: Thursday, February 27, 2020 8:49 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0


  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module 
will be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?



Without their free lunch?

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

None of those choices address what happens in the 1.0.2 module goes to historic 
on Sept 1.  See 
https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
 for details.

Re: OpenSSL 3.0

[Jason Schultz]

For option 2, we have a support contract in place. But does this actually help 
us as far as the FIPS Object Module?



From: openssl-users  on behalf of Neptune 

Sent: Thursday, February 27, 2020 8:56 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0

You essentially have three choices:
1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
year without support or security patches.
2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
to receive patches on 1.0.2 for the remainder of the year.
3. Pay SafeLogic for support contract to receive 1.0.2 security patches
through the year. Cost is roughly half what OpenSSL is asking, but you may
be able to negotiate.

These are the only options of which I am aware.




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

  *   That's fair. So the only option is to use another module? Extended 1.0.2 
support does not resolve this either, correct?

I do not think that is the only option.  For example, you might be able to use 
3.0 and say it’s “in evaluation.” There might be other options, that was all I 
could think of while composing this email.

HOWEVER, note that the set of validated platforms for 3.0 is very different 
from the current FOM.  Someone officially with the project will have to provide 
details on that, not me.

Re: OpenSSL 3.0

[Neptune]

You essentially have three choices:
1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
year without support or security patches.
2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
to receive patches on 1.0.2 for the remainder of the year.
3. Pay SafeLogic for support contract to receive 1.0.2 security patches
through the year. Cost is roughly half what OpenSSL is asking, but you may
be able to negotiate.

These are the only options of which I am aware.




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module 
will be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?

Without their free lunch?

Re: OpenSSL 3.0

[Jason Schultz]

Thanks for all of the responses. This question has led to other related topics, 
so I have another one. According to this blog:

https://keypair.us/2019/12/rip-fips-186-2/

The OpenSSL FIPS Object Module will be moved to the CMVP historical list as of 
9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module will 
be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?




From: openssl-users  on behalf of Salz, Rich 
via openssl-users 
Sent: Thursday, February 27, 2020 1:31 PM
To: Matt Caswell ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0


>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.

This needs to be real user documentation as part of the FIPS deliverable, right?

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.
  
This needs to be real user documentation as part of the FIPS deliverable, right?

Re: OpenSSL 3.0

[Matt Caswell]

On 26/02/2020 21:06, Dr Paul Dale wrote:
> 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.

It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.

We should certainly plan to have this in place by alpha1 IMO.

Matt


> 
> 
> 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
>> mailto:openssl-users@openssl.org>> 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: 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: OpenSSL 3.0

[Salz, Rich via openssl-users]

> 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: OpenSSL 3.0

[Sam Roberts]

On Wed, Feb 26, 2020 at 11:44 AM Salz, Rich  wrote:
>
> The 3.0 release is a work in progress and is not done yet.
>
> FIPS 3.0 === OpenSSL 3.0, using a FIPS-validated crypto provider which will 
> be part of OpenSSL 3.0.
>
> The architecture documents are at https://www.openssl.org/docs

Rich, I've seen all that, Matt says

> alpha1, 2020-03-31: Basic functionality plus basic FIPS module

That's 5 weeks from now, I'd thought the basic structure might be present now.

I'm willing to start some testing now to give early feedback, and to
get a sense of what will involved in porting Node.js.

If asking for information is too distracting, no problem, I'll wait
another month for the alpha and hope it contains some info on how to
do this:

> using a FIPS-validated crypto provider

Cheers,
Sam

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

The 3.0 release is a work in progress and is not done yet.

FIPS 3.0 === OpenSSL 3.0, using a FIPS-validated crypto provider which will be 
part of OpenSSL 3.0.

The architecture documents are at https://www.openssl.org/docs

On 2/26/20, 2:40 PM, "Sam Roberts"  wrote:

On Wed, Feb 26, 2020 at 8:36 AM Salz, Rich  wrote:
>
> >I'd like to give this a spin, to get an idea what's going to be
> involved in porting from FIPS2.0 to 3.0, any pointers on where to
> start?
>
> Per the blog post, "most applications should just need to be recompiled." 
:)
>
> Get the source via instructions here: https://www.openssl.org/source/

I want to build against ***FIPS3.0***. I don't find any routes to
FIPS3.0 in the above link.

We've already ported to openssl 1.1.1, so the non-FIPS APIs should be
fine when compiled against openssl-3.0 (the promise was API
compatible).

My expectations based on the blog posts and arch/design docs is the
FIPS3.0 will be an OpenSSL 3.0 provider, and I am guessing it will be
necessary, somehow?, to tell OpenSSL which provider to use, either
programmatically or via openssl.cfg?

Or maybe I'm off track, and its a configure mode, and the provider
will be hard-coded in if openssl-3.0 is built with FIPS? But again,
how to do that?

I've spent some time poking around in the source and git logs, and
(again, could have missed it), I didn't see any FIPS specific doc
changes or hints as what to do for FIPS3.0, and it wasn't clear where
to start.

Sam

Re: OpenSSL 3.0

[Sam Roberts]

On Wed, Feb 26, 2020 at 8:36 AM Salz, Rich  wrote:
>
> >I'd like to give this a spin, to get an idea what's going to be
> involved in porting from FIPS2.0 to 3.0, any pointers on where to
> start?
>
> Per the blog post, "most applications should just need to be recompiled." :)
>
> Get the source via instructions here: https://www.openssl.org/source/

I want to build against ***FIPS3.0***. I don't find any routes to
FIPS3.0 in the above link.

We've already ported to openssl 1.1.1, so the non-FIPS APIs should be
fine when compiled against openssl-3.0 (the promise was API
compatible).

My expectations based on the blog posts and arch/design docs is the
FIPS3.0 will be an OpenSSL 3.0 provider, and I am guessing it will be
necessary, somehow?, to tell OpenSSL which provider to use, either
programmatically or via openssl.cfg?

Or maybe I'm off track, and its a configure mode, and the provider
will be hard-coded in if openssl-3.0 is built with FIPS? But again,
how to do that?

I've spent some time poking around in the source and git logs, and
(again, could have missed it), I didn't see any FIPS specific doc
changes or hints as what to do for FIPS3.0, and it wasn't clear where
to start.

Sam

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

>I'd like to give this a spin, to get an idea what's going to be
involved in porting from FIPS2.0 to 3.0, any pointers on where to
start?
  
Per the blog post, "most applications should just need to be recompiled." :)

Get the source via instructions here: https://www.openssl.org/source/

Re: OpenSSL 3.0

[Sam Roberts]

On Tue, Feb 25, 2020 at 8:00 PM Matt Caswell  wrote:
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module

I'd like to give this a spin, to get an idea what's going to be
involved in porting from FIPS2.0 to 3.0, any pointers on where to
start?

Sam

Re: OpenSSL 3.0

[Matt Caswell]

On 25/02/2020 19:07, Jason Schultz wrote:
> Greetings. It has been several months since this blog post on OpenSSL 3.0:
> 
> https://www.openssl.org/blog/blog/2019/11/07/3.0-update/
> 
> “We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020.”
> 
> Is OpenSSL 3.0 still expected to reach code completion at the end of Q2
> this year? Also, by “final release” I’m assuming that means the first
> official, non-beta/dev release?


Since the publication of the blog post we published a more detailed
timeline. See the list of alpha/beta release about 2/3 the way down this
page:

https://www.openssl.org/policies/releasestrat.html

alpha1, 2020-03-31: Basic functionality plus basic FIPS module
alpha2, 2020-04-21: Complete external provider support (serialization,
support for new algs, support for providers which only include
operations in a class)
alpha3, 2020-05-21: Aiming to test the API completeness before beta1
freezes it)
beta1, 2020-06-02: Code complete (API stable, feature freeze)
betaN: Other beta releases TBD
Final: 2020 early Q4

We are currently still on target for this timeline and are aiming for
alpha1 at the end of March, with a final release in Q4. The final
release does indeed mean the first official non-beta/dev release -
although note that actual validation of the FIPS module may follow
sometime later.

Matt

Re: Openssl 3.0 fips usage

[Salz, Rich via openssl-users]

  *   If  both default and fips provider are loaded and application generate 
Rsa key pair(2048 bits) from fips provider and  try to use default provider to 
sign with sha1,  is this allowed?

The application will have to explicitly “export” the key from the FIPS provider 
and “import” it into the default (non-FIPS) provider. So you can share keys. 
Whether or not that is allowed would perhaps depend on the details of the 
export/import process and key protection required by FIPS. I think you would 
have to get an accredited validation lab to answer that question for you.

HOWEVER, this doesn’t your real question:


  *   According to FIPS 140-2 IG document, CSP defined in approved mode of 
operation shall not be accessed or shared with non-approved mode of  
operation.If allowed, will it not break the fips rules?

The OpenSSL FIPS-validated provider will only operate in FIPS mode and will not 
have a non-approved mode of operation as long as you follow the configuration 
and installation procedures (not yet written).

Disclaimer: I am not employed by an accredited lab.

Re: OpenSSL 3.0 (or 4.0) API goals

[Matt Caswell]

On 04/03/2019 12:57, Hubert Kario wrote:
> On Monday, 4 March 2019 12:59:26 CET Matt Caswell wrote:
>> On 01/03/2019 22:26, Paul Smith wrote:
>>> Hi all.
>>>
>>> I'm reading with interest the details coming out with respect to the
>>> next release of OpenSSL.
>>>
>>> I'm curious if there's any consideration being given to updating the
>>> API for existing interfaces, and/or checking the APIs of any new
>>> interfaces for issues that are seen in the current API.
>>>
>>> I'm talking about things like:
>>>  * Const-correctness for arguments
>>
>> const correctness is an ongoing thing. I'd welcome PRs that address this.
>>
>>>  * Signed vs. unsigned values for integer values
>>
>> We did do quite a bit of work internally in libssl to implement more
>> consistent use of size_t where appropriate. We need to do something similar
>> in libcrypto although that's probably a much bigger job. Dealing with
>> things internally is much easier than changing the API - because that is
>> obviously a breaking change which we try to avoid where possible.
> 
> In the past 9 years OpenSSL broke ABI/API 2 times (0.9.x to 1.0.0 and 1.0.2 
> to 
> 1.1.0) and announced a third. I think it's far too often for such a critical 
> and integral part of operating systems.
> 
> IMNSHO such API cleanup should be mandatory part of the OpenSSL 3.0 (4.0) 
> deliverable.
> 

Well what we said about OpenSSL 3.0 is:

"OpenSSL 3.0 is a major release and will be a significant change to the internal
architecture of OpenSSL. We plan to keep impacts on existing end user
applications to an absolute minimum with the intention that the vast majority of
existing well-behaved applications will just need to be recompiled. No
deprecated APIs will be removed in this release."

(from my blog post).

And:

"The OpenSSL 3.0 release will have minimal impact to the vast majority
of existing applications; almost all well-behaved applications will
just need to be recompiled."


So ABI compatibility won't be maintained. But I expect API compatibility largely
will. I do not expect the 1.1.1 -> 3.0 move to be anything like the 1.0.2 ->
1.1.0 move. While a recompile will be necessary, the intention is that, in most
cases, that will be all.

Matt

Re: OpenSSL 3.0 (or 4.0) API goals

[Hubert Kario]

On Monday, 4 March 2019 12:59:26 CET Matt Caswell wrote:
> On 01/03/2019 22:26, Paul Smith wrote:
> > Hi all.
> > 
> > I'm reading with interest the details coming out with respect to the
> > next release of OpenSSL.
> > 
> > I'm curious if there's any consideration being given to updating the
> > API for existing interfaces, and/or checking the APIs of any new
> > interfaces for issues that are seen in the current API.
> > 
> > I'm talking about things like:
> >  * Const-correctness for arguments
> 
> const correctness is an ongoing thing. I'd welcome PRs that address this.
> 
> >  * Signed vs. unsigned values for integer values
> 
> We did do quite a bit of work internally in libssl to implement more
> consistent use of size_t where appropriate. We need to do something similar
> in libcrypto although that's probably a much bigger job. Dealing with
> things internally is much easier than changing the API - because that is
> obviously a breaking change which we try to avoid where possible.

In the past 9 years OpenSSL broke ABI/API 2 times (0.9.x to 1.0.0 and 1.0.2 to 
1.1.0) and announced a third. I think it's far too often for such a critical 
and integral part of operating systems.

IMNSHO such API cleanup should be mandatory part of the OpenSSL 3.0 (4.0) 
deliverable.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.

Re: OpenSSL 3.0 (or 4.0) API goals

[Richard Levitte]

Matt Caswell  skrev: (4 mars 2019 12:59:26 CET)
>
>
>On 01/03/2019 22:26, Paul Smith wrote:
>> Hi all.
>> 
>> I'm reading with interest the details coming out with respect to the
>> next release of OpenSSL.
>> 
>> I'm curious if there's any consideration being given to updating the
>> API for existing interfaces, and/or checking the APIs of any new
>> interfaces for issues that are seen in the current API.
>> 
>> I'm talking about things like:
>> 
>>  * Const-correctness for arguments
>
>const correctness is an ongoing thing. I'd welcome PRs that address
>this.

Incidentally, I looked at clang-tidy today. It seems to have some helpful 
options for this kind of work. 

>
>>  * Signed vs. unsigned values for integer values
>
>We did do quite a bit of work internally in libssl to implement more
>consistent
>use of size_t where appropriate. We need to do something similar in
>libcrypto
>although that's probably a much bigger job. Dealing with things
>internally is
>much easier than changing the API - because that is obviously a
>breaking change
>which we try to avoid where possible.
>
>>  * Avoiding non-portable types in the API (the most obvious example:
>>using "int" as the type for socket descriptors, which is only
>>portable to Windows due to an implementation detail).
>
>I would hope that we're not introducing any new instances of this. Any
>that we
>have are likely to be historical. Removing such instances would be a
>matter of
>deprecating the relevant APIs and making sure they have suitable
>portable
>replacements in place.
>
>>  * Possibly using something like uint8_t* for pointers to buffers
>>containing binary "stuff" (this could be more annoying than
>helpful,
>>requiring a lot of casting, so I'm not sure about that).
>> 
>> Just wondering... seems like a good time to think about cleanups like
>> that, if feasible.
>> 
>
>
>
>On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote:
>> Also replacing all C macros such as those for SSL_CTX_ctrl with
>proper
>> external functions.
>>
>> This will ease use of OpenSSL with languages other than C, where we
>> currently have to code functions to replace the macros.
>>
>> Google did this when creating BoringSSL, there may be other similar
>> 'improvements' that could help OpenSSL.
>
>I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think
>the
>"ctrl" pattern adds much value. All SSL_METHOD implementations share
>the same
>ctrl implementation, with the exception of DTLS which adds a few extra
>ctrls.
>
>For other areas that may not be the case. For example with BIO_ctrl all
>the
>different BIO_METHODs all have quite separate ctrl implementations so
>there
>seems a bigger benefit to this pattern there.
>
>
>Matt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: OpenSSL 3.0 (or 4.0) API goals

[Matt Caswell]

On 01/03/2019 22:26, Paul Smith wrote:
> Hi all.
> 
> I'm reading with interest the details coming out with respect to the
> next release of OpenSSL.
> 
> I'm curious if there's any consideration being given to updating the
> API for existing interfaces, and/or checking the APIs of any new
> interfaces for issues that are seen in the current API.
> 
> I'm talking about things like:
> 
>  * Const-correctness for arguments

const correctness is an ongoing thing. I'd welcome PRs that address this.

>  * Signed vs. unsigned values for integer values

We did do quite a bit of work internally in libssl to implement more consistent
use of size_t where appropriate. We need to do something similar in libcrypto
although that's probably a much bigger job. Dealing with things internally is
much easier than changing the API - because that is obviously a breaking change
which we try to avoid where possible.

>  * Avoiding non-portable types in the API (the most obvious example:
>using "int" as the type for socket descriptors, which is only
>portable to Windows due to an implementation detail).

I would hope that we're not introducing any new instances of this. Any that we
have are likely to be historical. Removing such instances would be a matter of
deprecating the relevant APIs and making sure they have suitable portable
replacements in place.

>  * Possibly using something like uint8_t* for pointers to buffers
>containing binary "stuff" (this could be more annoying than helpful,
>requiring a lot of casting, so I'm not sure about that).
> 
> Just wondering... seems like a good time to think about cleanups like
> that, if feasible.
> 



On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote:
> Also replacing all C macros such as those for SSL_CTX_ctrl with proper
> external functions.
>
> This will ease use of OpenSSL with languages other than C, where we
> currently have to code functions to replace the macros.
>
> Google did this when creating BoringSSL, there may be other similar
> 'improvements' that could help OpenSSL.

I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think the
"ctrl" pattern adds much value. All SSL_METHOD implementations share the same
ctrl implementation, with the exception of DTLS which adds a few extra ctrls.

For other areas that may not be the case. For example with BIO_ctrl all the
different BIO_METHODs all have quite separate ctrl implementations so there
seems a bigger benefit to this pattern there.


Matt

Re: OpenSSL 3.0 (or 4.0) API goals

[Angus Robertson - Magenta Systems Ltd]

> I'm curious if there's any consideration being given to updating 
> the API for existing interfaces, and/or checking the APIs of any new
> interfaces for issues that are seen in the current API.

Also replacing all C macros such as those for SSL_CTX_ctrl with proper
external functions.

This will ease use of OpenSSL with languages other than C, where we
currently have to code functions to replace the macros.  

Google did this when creating BoringSSL, there may be other similar
'improvements' that could help OpenSSL. 

Angus

Re: OpenSSL 3.0 vs. SSL 3.0

[Daniel Kahn Gillmor]

On Wed 2019-02-27 16:02:32 +0100, Christian Heimes wrote:
> In my humble opinion, it's problematic and confusing to use "OpenSSL
> 3.0" for the next major version of OpenSSL and first release of
> OpenSSL with SSL 3.0 support.

Sigh.  You're right, but i wish you weren't. :)

Part of the problem of course is the "SSL" in "OpenSSL" itself, which
has held back the industry from adopting the more accurate "TLS" label.
But i understand the value of the brand, and why that won't be changed
either.

fwiw, i support the suggestion to skip 3.0, and call it OpenSSL 4.0
directly.  Reducing confusion matters.

   --dkg

Re: OpenSSL 3.0 vs. SSL 3.0

[Christian Heimes]

On 27/02/2019 19.53, Michael Richardson wrote:
> 
> Christian Heimes  wrote:
> > I'm concerned about the version number of the upcoming major release of
> > OpenSSL. "OpenSSL 3.0" just sounds and looks way too close to "SSL 3.0".
> > It took us more than a decade to teach people that SSL 3.0 is bad and
> > should be avoided in favor of TLS. In my humble opinion, it's
> > problematic and confusing to use "OpenSSL 3.0" for the next major
> > version of OpenSSL and first release of OpenSSL with SSL 3.0 support.
> 
> You make a good point which I had not thought about, having exhumed SSLx.y
> From my brain.  +5
> 
> > You skipped version 2.0 for technical reasons, because (IIRC) 2.0 was
> > used / reserved for FIPS mode. May I suggest that you also skip 3.0 for
> > UX reasons and call the upcoming version "OpenSSL 4.0". That way you can
> > avoid any confusion with SSL 3.0.
> 
> Integers are cheap.
> And 4.0 is > 3.0, so (Open)SSL 4.0.0 must be better than SSL3.

Thanks for your support!

I have created PR https://github.com/openssl/openssl/pull/8367 to bump
the version number to 4.0.0.

Christian



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 3.0 vs. SSL 3.0

[Michael Richardson]

Christian Heimes  wrote:
> I'm concerned about the version number of the upcoming major release of
> OpenSSL. "OpenSSL 3.0" just sounds and looks way too close to "SSL 3.0".
> It took us more than a decade to teach people that SSL 3.0 is bad and
> should be avoided in favor of TLS. In my humble opinion, it's
> problematic and confusing to use "OpenSSL 3.0" for the next major
> version of OpenSSL and first release of OpenSSL with SSL 3.0 support.

You make a good point which I had not thought about, having exhumed SSLx.y
From my brain.  +5

> You skipped version 2.0 for technical reasons, because (IIRC) 2.0 was
> used / reserved for FIPS mode. May I suggest that you also skip 3.0 for
> UX reasons and call the upcoming version "OpenSSL 4.0". That way you can
> avoid any confusion with SSL 3.0.

Integers are cheap.
And 4.0 is > 3.0, so (Open)SSL 4.0.0 must be better than SSL3.

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



signature.asc
Description: PGP signature