Elimination of some sources not needed in the FIPS_MODULE

Unfortunately in terms of fips.sources this does not mean much
given the way how the .h files are added via the dependency
i

Elimination of some sources not needed in the FIPS_MODULE

Unfortunately in terms of fips.sources this does not mean much
given the way how the .h files are added via the dependency
information from the compiler.

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

show more ...

Update copyright year

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

Add ossl_rand symbols

Partial fix for #12964

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

rand_drbg: remove RAND_DRBG.

The RAND_DRBG API did not fit well into the new provider concept as
implemented by EVP_RAND and EVP_RAND_CTX. The main reason is that the
RAND_DRBG API i

rand_drbg: remove RAND_DRBG.

The RAND_DRBG API did not fit well into the new provider concept as
implemented by EVP_RAND and EVP_RAND_CTX. The main reason is that the
RAND_DRBG API is a mixture of 'front end' and 'back end' API calls
and some of its API calls are rather low-level. This holds in particular
for the callback mechanism (RAND_DRBG_set_callbacks()) and the RAND_DRBG
type changing mechanism (RAND_DRBG_set()).

Adding a compatibility layer to continue supporting the RAND_DRBG API as
a legacy API for a regular deprecation period turned out to come at the
price of complicating the new provider API unnecessarily. Since the
RAND_DRBG API exists only since version 1.1.1, it was decided by the OMC
to drop it entirely.

Other related changes:

Use RNG instead of DRBG in EVP_RAND documentation. The documentation was
using DRBG in places where it should have been RNG or CSRNG.

Move the RAND_DRBG(7) documentation to EVP_RAND(7).

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12509)

show more ...

DRBG: rename the DRBG taxonomy.

The existing wording didn't capture the reality of the default setup, this new
nomenclature attempts to improve the situation.

Reviewed-by: Mark

DRBG: rename the DRBG taxonomy.

The existing wording didn't capture the reality of the default setup, this new
nomenclature attempts to improve the situation.

Reviewed-by: Mark J. Cox <mark@awe.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12366)

show more ...

CTR, HASH and HMAC DRBGs in provider

Move the three different DRBGs to the provider.

As part of the move, the DRBG specific data was pulled out of a common
structure and into th

CTR, HASH and HMAC DRBGs in provider

Move the three different DRBGs to the provider.

As part of the move, the DRBG specific data was pulled out of a common
structure and into their own structures. Only these smaller structures are
securely allocated. This saves quite a bit of secure memory:

+-------------------------------+
| DRBG | Bytes | Secure |
+--------------+-------+--------+
| HASH | 376 | 512 |
| HMAC | 168 | 256 |
| CTR | 176 | 256 |
| Common (new) | 320 | 0 |
| Common (old) | 592 | 1024 |
+--------------+-------+--------+

Bytes is the structure size on the X86/64.
Secure is the number of bytes of secure memory used (power of two allocator).

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)

show more ...

CRNGT: continuous DRBG tests for providers

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)

Rename FIPS_MODE to FIPS_MODULE

This macro is used to determine if certain pieces of code should
become part of the FIPS module or not. The old name was confusing.

Fixes #11538

Rename FIPS_MODE to FIPS_MODULE

This macro is used to determine if certain pieces of code should
become part of the FIPS module or not. The old name was confusing.

Fixes #11538

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11539)

show more ...

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11616)

AES CTR-DRGB: performance improvement

Optimize the the AES-based implementation of the CTR_DRBG
construction, see 10.2.1 in [1].
Due to the optimizations, the code may deviate (more)

AES CTR-DRGB: performance improvement

Optimize the the AES-based implementation of the CTR_DRBG
construction, see 10.2.1 in [1].
Due to the optimizations, the code may deviate (more) from the
pseudocode in [1], but it is functional equivalence being decisive
for compliance:

"All DRBG mechanisms and algorithms are described in this document
in pseudocode, which is intended to explain functionality.
The pseudocode is not intended to constrain real-world
implementations." [9 in [1]].

The following optimizations are done:

- Replace multiple plain AES encryptions by a single AES-ECB
encryption of a corresponding pre-initialized buffer, where
possible.
This allows platform-specific AES-ECB support to
be used and reduces the overhead of multiple EVP calls.

- Replace the generate operation loop (which is a counter
increment followed by a plain AES encryption) by a
loop which does a plain AES encryption followed by
a counter increment. The latter loop is just a description
of AES-CTR, so we replace it by a single AES-CTR
encryption.
This allows for platform-specific AES-CTR support to be used
and reduces the overhead of multiple EVP calls.
This change, that is, going from a pre- to a post- counter
increment, requires the counter in the internal state
to be kept at "+1" (compared to the pseudocode in [1])
such that it is in the correct state, when a generate
operation is called.
That in turn also requires all other operations to be
changed from pre- to post-increment to keep functional
equivalence.

[1] NIST SP 800-90A Revision 1

Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10457)

show more ...

RAND_DRBG: add a callback data for entropy and nonce callbacks

The callback data allows passing context specific data from the
application of the DRBG to to the entropy callbacks.
Th

RAND_DRBG: add a callback data for entropy and nonce callbacks

The callback data allows passing context specific data from the
application of the DRBG to to the entropy callbacks.
This a rather specialized feature which is useful for implementing
known answer tests (KATs) or deterministic signatures (RFC6979),
which require passing a specified entropy and nonce for instantiating
the DRBG.

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

show more ...

Fix misspelling errors and typos reported by codespell

Fixes #10998

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

Fix misspelling errors and typos reported by codespell

Fixes #10998

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

show more ...

CRYPTO: Remove support for ex_data fields when building the FIPS module

These fields are purely application data, and applications don't reach
into the bowels of the FIPS module, so thes

CRYPTO: Remove support for ex_data fields when building the FIPS module

These fields are purely application data, and applications don't reach
into the bowels of the FIPS module, so these fields are never used
there.

Fixes #10835

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10837)

show more ...

Fix header file include guard names

Make the include guards consistent by renaming them systematically according
to the naming conventions below

For the public header files (in

Fix header file include guard names

Make the include guards consistent by renaming them systematically according
to the naming conventions below

For the public header files (in the 'include/openssl' directory), the guard
names try to match the path specified in the include directives, with
all letters converted to upper case and '/' and '.' replaced by '_'. For the
private header files files, an extra 'OSSL_' is added as prefix.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)

show more ...

Reorganize local header files

Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
direc

Reorganize local header files

Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like

'*_lcl.h', '*_local.h', or '*_int.h'

This commit changes the different suffixes to '*_local.h' uniformly.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)

show more ...