fips: continuous random bit generator tests

For FIPS 140-3 the continuous tests specified in SP 800-90B need to be
included on the output of any entropy source.

They are impleme

fips: continuous random bit generator tests

For FIPS 140-3 the continuous tests specified in SP 800-90B need to be
included on the output of any entropy source.

They are implemented here as a replacement for the primary DRBG in the FIPS
provider. This results in a setup that looks like this:

+-------------+
| |
| Seed Source |
| |
+------+------+
|
|
v
+-------------+
| |
| CRNG Test |
| |
++----------+-+
| |
| |
v v
+--------------+ +--------------+
| | | |
| Public DRBG | | Private DRBG |
| | | |
+--------------+ +--------------+

An additional benefit, that of avoiding DRBG chains, is also gained.
The current standards do not permit the output of one DRBG to be used
as the input for a second (i.e. a chain).

This also leaves open the future possibility of incorporating a seed
source inside the FIPS boundary.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25415)

show more ...

Update code to use EVP_MD_xof()

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25285)

Cleanups for FIPS options..

The options in fipsprov.c are now generated using macros with fips_indicator_params.inc.
This should keep the naming consistent.

Some FIPS related he

Cleanups for FIPS options..

The options in fipsprov.c are now generated using macros with fips_indicator_params.inc.
This should keep the naming consistent.

Some FIPS related headers have moved to providers/fips/include so that
they can use fips_indicator_params.inc.
securitycheck.h now includes fipsindicator.h, and fipsindicator.h includes
fipscommon.h.

fipsinstall.c uses OSSL_PROV_PARAM_ for the configurable FIPS options rather than
using OSSL_PROV_FIPS_PARAM_* as this was confusing as to which one should be used.
fips_names.h just uses aliases now for existing public names.

Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25162)

show more ...

drbg: streamline test for allowed digests

Under FIPS, we've got a whitelist of algorithms. There is no need to then
also check for XOF digests because they aren't possible.

Rev

drbg: streamline test for allowed digests

Under FIPS, we've got a whitelist of algorithms. There is no need to then
also check for XOF digests because they aren't possible.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25007)

show more ...

Remove trailing whitespace

Found by running the checkpatch.pl Linux script to enforce coding style.

Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: David von Oheimb

Remove trailing whitespace

Found by running the checkpatch.pl Linux script to enforce coding style.

Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22097)

show more ...

Change all existing FIPS configurable checks to use FIPS indicators.

This changes the logic to always do the security checks and then decide
what to do based on if this passes or not. Fa

Change all existing FIPS configurable checks to use FIPS indicators.

This changes the logic to always do the security checks and then decide
what to do based on if this passes or not. Failure of a check causes
either a failure OR the FIPS indicator callback to be triggered.

Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24623)

show more ...

Clarify DRBG seeding.

There is a legacy code path that OpenSSL won't use anymore but applications
could. Add a comment indicating this to avoid confusion for people not
intimately c

Clarify DRBG seeding.

There is a legacy code path that OpenSSL won't use anymore but applications
could. Add a comment indicating this to avoid confusion for people not
intimately conversant with the nuances in the RNG code.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24745)

show more ...

Fix typos found by codespell

Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24013)

Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Lan

Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)

show more ...

Fix memory leaks on error cases during drbg initializations

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.

Fix memory leaks on error cases during drbg initializations

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/23503)

show more ...

fix indentation

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21964)

Copyright year updates


Reviewed-by: Richard Levitte <levitte@openssl.org>
Release: yes

Coverity 1531836: Check return value of CRYPTO_atomic_add()

Enable obtaining certain DRBG params without a lock

Even if a DRBG has locking enabled on it, there are certain parameters
which are still safe to obtain even without a lock. The max_req

Enable obtaining certain DRBG params without a lock

Even if a DRBG has locking enabled on it, there are certain parameters
which are still safe to obtain even without a lock. The max_request
value is constant for all our DRBGs. The reseed_counter does not matter
if we get it wrong - so it is safe to avoid the lock. So if all we are
reading are those parameters then we take no lock at all.

Partially fixes #20286

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20970)

show more ...

Refactor the DRBG implementations to manage locking themselves

Previously the EVP layer would call lock and unlock functions on the
underlying DRBG implementation to say when a lock shou

Refactor the DRBG implementations to manage locking themselves

Previously the EVP layer would call lock and unlock functions on the
underlying DRBG implementation to say when a lock should be acquired and
released. This gives the DRBG implementation no say as to what kind of
lock should obtained (e.g. read/write) or even whether a lock is actually
needed or not.

In reality we know whether a DRBG is supposed to be in locking mode or
not because the "enable_locking()" function will have been called if
locks should be used. Therefore we re-interpret the lock and unlock
functions as "hints" from the EVP layer which we ignore. Instead we
acquire locks only when we need them. By knowing the context we can obtain
either a read or a write lock as appropriate.

This may mean that in some rare cases we acquire the locks more than once
for a single EVP call, if the EVP call makes several calls to the underlying
DRBG. But in practice almost all EVP calls only make one such call.
EVP_RAND_generate() is an example of a call where multiple DRBG calls may
be made. One of these gets the "max_request" parameter (which is constant
for all of our own DRBGs) and it may make several calls to the DRBG generate
call - but only if the requested size is very large which will rarely be
the case.

Partially fixes #20286

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20970)

show more ...

Declare FIPS option functions in their own header

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/open

Declare FIPS option functions in their own header

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20521)

show more ...

DRBG: restrict the digests that can be used with HMAC and Hash DRBGs.

According to FIP 140-3 IG D.R: https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documen

DRBG: restrict the digests that can be used with HMAC and Hash DRBGs.

According to FIP 140-3 IG D.R: https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

Outside of FIPS, there remains no restriction other than not allowing
XOF digests.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20521)

show more ...

Segmentation fault in parent rng cleanup

CLA: trivial
When `cleanup_entropy()` is called to cleanup parent by calling
provided `OSSL_FUNC_rand_clear_seed_fn` method, incorrect random

Segmentation fault in parent rng cleanup

CLA: trivial
When `cleanup_entropy()` is called to cleanup parent by calling
provided `OSSL_FUNC_rand_clear_seed_fn` method, incorrect random
context is passed to the method. So accessing that context creates
a segmentation fault. Parent context should be passed rather than
DRBG's own context.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20454)

show more ...

Stop raising ERR_R_MALLOC_FAILURE in most places

Since OPENSSL_malloc() and friends report ERR_R_MALLOC_FAILURE, and
at least handle the file name and line number they are called from,

Stop raising ERR_R_MALLOC_FAILURE in most places

Since OPENSSL_malloc() and friends report ERR_R_MALLOC_FAILURE, and
at least handle the file name and line number they are called from,
there's no need to report ERR_R_MALLOC_FAILURE where they are called
directly, or when SSLfatal() and RLAYERfatal() is used, the reason
`ERR_R_MALLOC_FAILURE` is changed to `ERR_R_CRYPTO_LIB`.

There were a number of places where `ERR_R_MALLOC_FAILURE` was reported
even though it was a function from a different sub-system that was
called. Those places are changed to report ERR_R_{lib}_LIB, where
{lib} is the name of that sub-system.
Some of them are tricky to get right, as we have a lot of functions
that belong in the ASN1 sub-system, and all the `sk_` calls or from
the CRYPTO sub-system.

Some extra adaptation was necessary where there were custom OPENSSL_malloc()
wrappers, and some bugs are fixed alongside these changes.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19301)

show more ...

Update copyright year

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Release: yes

Refactor OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA

This refactors OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA. The assorted
objects to be managed by OSSL_LIB_CTX are hardcoded and are in

Refactor OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA

This refactors OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA. The assorted
objects to be managed by OSSL_LIB_CTX are hardcoded and are initialized
eagerly rather than lazily, which avoids the need for locking on access
in most cases.

Fixes #17116.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17881)

show more ...

drbg: add handling for cases where TSAN isn't available

Most of the DRGB code is run under lock from the EVP layer. This is relied
on to make the majority of TSAN operations safe. Howe

drbg: add handling for cases where TSAN isn't available

Most of the DRGB code is run under lock from the EVP layer. This is relied
on to make the majority of TSAN operations safe. However, it is still necessary
to enable locking for all DRBGs created.

Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/17479)

show more ...

rand: don't free an mis-set pointer on error

This is adding robustness to the code. The fix to not mis-set the pointer
is in #16636.

Fixes #16631

Reviewed-by: Tomas Mr

rand: don't free an mis-set pointer on error

This is adding robustness to the code. The fix to not mis-set the pointer
is in #16636.

Fixes #16631

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16640)

show more ...

Add the ability for ex_data to have a priority

Where an object has multiple ex_data associated with it, then we free that
ex_data in order of priority (high priority first).

Rev

Add the ability for ex_data to have a priority

Where an object has multiple ex_data associated with it, then we free that
ex_data in order of priority (high priority first).

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14991)

show more ...

update set_ctx_param DRBG calls to return 1 for a NULL params

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14383)