RE: fips mode and key management
> >distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be > more fitting than FIPS_MODE? > > > Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use > OPENSSL_BUILDING_OPENSSL ... OPENSSL_BUILDING_OPENSSL is really a remarkably long name. I hope this does not blow up any commandline length limits 😉. How about using OSSL_LIBRARY library instead? This would fit nicely to OSSL_FIPS_PROVIDER: #ifdef OSSL_LIBRARY ... #endif #ifdef OSSL_FIPS_PROVIDER ... #endif > There's no reason to use OSSL for internal macros. But it avoids unnecessary name clashes with system headers. Just today, I saw this collision with Windows headers: include/openssl/types.h:74:# undef OCSP_REQUEST include/openssl/types.h:75:# undef OCSP_RESPONSE (Yes I know, Window headers are really polluting the global namespace).
Re: fips mode and key management
>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be more fitting than FIPS_MODE? Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use OPENSSL_BUILDING_OPENSSL ... There's no reason to use OSSL for internal macros.
Re: fips mode and key management
I can only add +1 to what Matthias suggests. Although I know the meaning of the FIPS_MODE define, for a newcomer it is obviously not clear what the define really means. Tomas On Tue, 2020-01-21 at 13:31 +0100, Matthias St. Pierre wrote: > On 21.01.20 10:36, Richard Levitte wrote: > > I think that the misunderstanding lies in when FIPS_MODE is > > defined. > > Reading this sentence it occurred to me that the misunderstanding > comes from > the fact that the define is indeed misnamed. The term "FIPS mode" is > a relict > from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable > FIPS mode > *at runtime*. > > (Note that the *compile time* option to include the FOM was called > OPENSSL_FIPS, > not FIPS_MODE. So the misleading name must have crept in only > recently.) > > > It's defined when the FIPS provider module is being built, never > > otherwise. > > Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are > partially built from > the same source files, which is the reason why we need a build time > constant to > distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would > be > more fitting than FIPS_MODE? > > > #ifdef OSSL_FIPS_PROVIDER > ... > #endif > > > Matthias > > > P.S: Even though it is an internal define, it should have an OSSL_ > prefix IMHO. > P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER, > OSSL_LEGACY_PROVIDER, ... > -- 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: fips mode and key management
BTW: the following build time constant with the remarkably long name seems to be intended for a related purpose, but it is currently completely unused?    Configurations/00-base-templates.conf: lib_defines => [ 'OPENSSL_BUILDING_OPENSSL' ],
Re: fips mode and key management
On 21.01.20 10:36, Richard Levitte wrote: I think that the misunderstanding lies in when FIPS_MODE is defined. Reading this sentence it occurred to me that the misunderstanding comes from the fact that the define is indeed misnamed. The term "FIPS mode" is a relict from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable FIPS mode *at runtime*. (Note that the *compile time* option to include the FOM was called OPENSSL_FIPS, not FIPS_MODE. So the misleading name must have crept in only recently.) It's defined when the FIPS provider module is being built, never otherwise. Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are partially built from the same source files, which is the reason why we need a build time constant to distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be more fitting than FIPS_MODE? Â Â Â #ifdef OSSL_FIPS_PROVIDER Â Â Â ... Â Â Â #endif Matthias P.S: Even though it is an internal define, it should have an OSSL_ prefix IMHO. P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER, OSSL_LEGACY_PROVIDER, ...
Re: fips mode and key management
This doesn't affect applications. Our FIPS module holds its own
keys, but reuse the same structures as libcrypto to hold them
internally, and *there*, the EX_DATA field is irrelevant.
Applications will never get that far in. The EX_DATA added by the
application is still valid.
I think that the misunderstanding lies in when FIPS_MODE is defined.
It's defined when the FIPS provider module is being built, never
otherwise.
Cheers,
Richard
On Sat, 18 Jan 2020 12:19:25 +0100,
Roumen Petrov wrote:
>
> Hello,
>
> Recently I note that when build is in FIPS_MODE some functionality is
> lost. For instance RSA_{g|s}et_ex_data is not available.
>
> Reading the code I expect that in FIPS mode use of external keys is
> forbidden.
> Remark: ex_data is used to store reference information for external keys.
>
> Please confirm that in FIPS mode we could use external keys?
>
>
> Regards
> Roumen Petrov
>
> P.S. If is not allowed this regression to previous FIPS
> releases(validations).
> Neither OpenSSL nor Red Hat nor Solaris FIPS validation forbid use of
> "external" keys.
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
fips mode and key management
Hello,
Recently I note that when build is in FIPS_MODE some functionality is
lost. For instance RSA_{g|s}et_ex_data is not available.
Reading the code I expect that in FIPS mode use of external keys is
forbidden.
Remark: ex_data is used to store reference information for external keys.
Please confirm that in FIPS mode we could use external keys?
Regards
Roumen Petrov
P.S. If is not allowed this regression to previous FIPS
releases(validations).
Neither OpenSSL nor Red Hat nor Solaris FIPS validation forbid use of
"external" keys.
