Make EVP_PKEY_check() be an alias for EVP_PKEY_pairwise_check()

The implementation of EVP_PKEY_pairwise_check() is also changed
to handle the legacy keys.

Fixes #16046

Make EVP_PKEY_check() be an alias for EVP_PKEY_pairwise_check()

The implementation of EVP_PKEY_pairwise_check() is also changed
to handle the legacy keys.

Fixes #16046

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16069)

show more ...

fips module header inclusion fine-tunning

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>

fips module header inclusion fine-tunning

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15974)

show more ...

Add EVP_PKEY_public_check_quick.

Adding the EVP_PKEY_param_check_quick() reminded me that there are also
partial checks for public keys as part of SP800-56A for FFC (DH named safe
pr

Add EVP_PKEY_public_check_quick.

Adding the EVP_PKEY_param_check_quick() reminded me that there are also
partial checks for public keys as part of SP800-56A for FFC (DH named safe
prime groups) and ECC. The code was mainly already there and just needed
to be plumbed into the validate methods.

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

show more ...

Update copyright year

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

Implement EVP_PKEY_param_check_quick() and use it in libssl

The low level DH API has two functions for checking parameters:
DH_check_ex() and DH_check_params_ex(). The former does a "ful

Implement EVP_PKEY_param_check_quick() and use it in libssl

The low level DH API has two functions for checking parameters:
DH_check_ex() and DH_check_params_ex(). The former does a "full" check,
while the latter does a "quick" check. Most importantly it skips the
check for a safe prime. We're ok without using safe primes here because
we're doing ephemeral DH.

Now that libssl is fully using the EVP API, we need a way to specify that
we want a quick check instead of a full check. Therefore we introduce
EVP_PKEY_param_check_quick() and use it.

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14146)

show more ...

Convert all {NAME}err() in crypto/ to their corresponding ERR_raise() call

This includes error reporting for libcrypto sub-libraries in surprising
places.

This was done using ut

Convert all {NAME}err() in crypto/ to their corresponding ERR_raise() call

This includes error reporting for libcrypto sub-libraries in surprising
places.

This was done using util/err-to-raise

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13318)

show more ...

EVP: Have all EVP_PKEY check functions export to provider if possible

Fixes #13322

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>

EVP: Have all EVP_PKEY check functions export to provider if possible

Fixes #13322

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

show more ...

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 ...

EVP: Clarify the states of an EVP_PKEY

EVP_PKEY is rather complex, even before provider side keys entered the
stage.
You could have untyped / unassigned keys (pk->type == EVP_PKEY_NO

EVP: Clarify the states of an EVP_PKEY

EVP_PKEY is rather complex, even before provider side keys entered the
stage.
You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE),
keys that had been assigned a type but no data (pk->pkey.ptr == NULL),
and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL).

For provider side keys, the corresponding states weren't well defined,
and the code didn't quite account for all the possibilities.

We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so
they don't exist at all in the FIPS module.

Most of all, code needs to adapt to the case where an EVP_PKEY's
|keymgmt| is non-NULL, but its |keydata| is NULL.

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

show more ...

Rethink the EVP_PKEY cache of provider side keys

The role of this cache was two-fold:

1. It was a cache of key copies exported to providers with which an
operation was init

Rethink the EVP_PKEY cache of provider side keys

The role of this cache was two-fold:

1. It was a cache of key copies exported to providers with which an
operation was initiated.
2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was
the corresponding provider side origin, while the rest was the
actual cache.

This dual role for item 0 made the code a bit confusing, so we now
make a separate keymgmt / keydata pair outside of that cache, which is
the provider side "origin" key.

A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a
provider side "origin" at the same time.

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

show more ...

Redesign the KEYMGMT libcrypto <-> provider interface - the basics

The KEYMGMT libcrypto <-> provider interface currently makes a few
assumptions:

1. provider side domain param

Redesign the KEYMGMT libcrypto <-> provider interface - the basics

The KEYMGMT libcrypto <-> provider interface currently makes a few
assumptions:

1. provider side domain parameters and key data isn't mutable. In
other words, as soon as a key has been created in any (loaded,
imported data, ...), it's set in stone.
2. provider side domain parameters can be strictly separated from the
key data.

This does work for the most part, but there are places where that's a
bit too rigid for the functionality that the EVP_PKEY API delivers.
Key data needs to be mutable to allow the flexibility that functions
like EVP_PKEY_copy_parameters promise, as well as to provide the
combinations of data that an EVP_PKEY is generally assumed to be able
to hold:

- domain parameters only
- public key only
- public key + private key
- domain parameters + public key
- domain parameters + public key + private key

To remedy all this, we:

1. let go of the distinction between domain parameters and key
material proper in the libcrypto <-> provider interface.

As a consequence, functions that still need it gain a selection
argument, which is a set of bits that indicate what parts of the
key object are to be considered in a specific call. This allows
a reduction of very similar functions into one.

2. Rework the libcrypto <-> provider interface so provider side key
objects are created and destructed with a separate function, and
get their data filled and extracted in through import and export.

(future work will see other key object constructors and other
functions to fill them with data)

Fixes #10979

squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics

Remedy 1 needs a rewrite:

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

show more ...

Add RSA key validation to default provider

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