Don't hold a lock when calling a callback in ossl_namemap_doall_names

We don't want to hold a read lock when calling a user supplied callback.
That callback could do anything so the risk

Don't hold a lock when calling a callback in ossl_namemap_doall_names

We don't want to hold a read lock when calling a user supplied callback.
That callback could do anything so the risk of a deadlock is high.
Instead we collect all the names first inside the read lock, and then
subsequently call the user callback outside the read lock.

Fixes #14225

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

show more ...

Update copyright year

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

Pass correct maximum output length to provider derive operation

And improve error checking in EVP_PKEY_derive* calls.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from h

Pass correct maximum output length to provider derive operation

And improve error checking in EVP_PKEY_derive* calls.

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

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

Rename OPENSSL_CTX prefix to OSSL_LIB_CTX

Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix,
e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER.

Rename OPENSSL_CTX prefix to OSSL_LIB_CTX

Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix,
e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER.

The OPENSSL_CTX type stands out a little by using a different prefix.
For consistency reasons, this type is renamed to OSSL_LIB_CTX.

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

show more ...

EVP: use evp_pkey_ctx_is_legacy() to find what implementation to use

We've had explicit checks for when to fall back to legacy code for
operations that use an EVP_PKEY. Unfortunately, t

EVP: use evp_pkey_ctx_is_legacy() to find what implementation to use

We've had explicit checks for when to fall back to legacy code for
operations that use an EVP_PKEY. Unfortunately, the checks were
radically different in different spots, so we refactor that into a
macro that gets used everywhere.

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

show more ...

Add public API for gettables and settables for keymanagement, signatures and key exchange.

The openssl provider app will now display these params.

Reviewed-by: Matt Caswell <matt@op

Add public API for gettables and settables for keymanagement, signatures and key exchange.

The openssl provider app will now display these params.

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

show more ...

Implement a EVP_PKEY KDF to KDF provider bridge

Some KDF implementations were available before the current EVP_KDF API.
They were used via EVP_PKEY_derive. There exists a bridge between

Implement a EVP_PKEY KDF to KDF provider bridge

Some KDF implementations were available before the current EVP_KDF API.
They were used via EVP_PKEY_derive. There exists a bridge between the old
API and the EVP_KDF API however this bridge itself uses a legacy
EVP_PKEY_METHOD. This commit implements a provider side bridge without
having to use any legacy code.

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

show more ...

Make the naming scheme for dispatched functions more consistent

The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all
functions which are dispatched between the core a

Make the naming scheme for dispatched functions more consistent

The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all
functions which are dispatched between the core and providers.

This change includes in particular all up- and downcalls, i.e., the
dispatched functions passed from core to provider and vice versa.

- OSSL_core_ -> OSSL_FUNC_core_
- OSSL_provider_ -> OSSL_FUNC_core_

For operations and their function dispatch tables, the following convention
is used:

Type | Name (evp_generic_fetch(3)) |
---------------------|-----------------------------------|
operation | OSSL_OP_FOO |
function id | OSSL_FUNC_FOO_FUNCTION_NAME |
function "name" | OSSL_FUNC_foo_function_name |
function typedef | OSSL_FUNC_foo_function_name_fn |
function ptr getter | OSSL_FUNC_foo_function_name |

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

show more ...

Rename EVP_PKEY_cmp() to EVP_PKEY_eq() and EVP_PKEY_cmp_parameters() to EVP_PKEY_parameters_eq()

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

Rename EVP_PKEY_cmp() to EVP_PKEY_eq() and EVP_PKEY_cmp_parameters() to EVP_PKEY_parameters_eq()

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

show more ...

EVP: when setting the operation to EVP_PKEY_OP_UNDEFINED, clean up!

There were a few instances where we set the EVP_PKEY_CTX operation to
EVP_PKEY_OP_UNDEFINED, but forgot to clean up fi

EVP: when setting the operation to EVP_PKEY_OP_UNDEFINED, clean up!

There were a few instances where we set the EVP_PKEY_CTX operation to
EVP_PKEY_OP_UNDEFINED, but forgot to clean up first. After the
operation is made undefined, there's no way to know what should be
cleaned away, so that must be done first, in all spots.

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

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

Update copyright year

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

EVP: fetch the EVP_KEYMGMT earlier

Instead of fetching the EVP_KEYMGMT in the init for every different
operation, do it when creating the EVP_PKEY_CTX.

This allows certain contr

EVP: fetch the EVP_KEYMGMT earlier

Instead of fetching the EVP_KEYMGMT in the init for every different
operation, do it when creating the EVP_PKEY_CTX.

This allows certain control functions to be called between the
creation of the EVP_PKEY_CTX and the call of the operation's init
function.

Use case: EVP_PKEY_CTX_set1_id(), which is allowed to be called very
early with the legacy implementation, this should still be allowed
with provider implementations.

Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/11343)

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

Refactor evp_pkey_make_provided() to do legacy to provider export

Previously, evp-keymgmt_util_export_to_provider() took care of all
kinds of exports of EVP_PKEYs to provider side keys,

Refactor evp_pkey_make_provided() to do legacy to provider export

Previously, evp-keymgmt_util_export_to_provider() took care of all
kinds of exports of EVP_PKEYs to provider side keys, be it from its
legacy key or from another provider side key. This works most of the
times, but there may be cases where the caller wants to be a bit more
in control of what sort of export happens when.

Also, when it's time to remove all legacy stuff, that job will be much
easier if we have a better separation between legacy support and
support of provided stuff, as far as we can take it.

This changes moves the support of legacy key to provider side key
export from evp-keymgmt_util_export_to_provider() to
evp_pkey_make_provided(), and makes sure the latter is called from all
EVP_PKEY functions that handle legacy stuff.

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/11074)

show more ...

[PROV][KMGMT][KEXCH][EC] Implement EC keymgtm and ECDH

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shan

[PROV][KMGMT][KEXCH][EC] Implement EC keymgtm and ECDH

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

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

Reorganize the internal evp_keymgmt functions

Some of the evp_keymgmt_ functions are just wrappers around the
EVP_KEYMGMT function pointers. We move those from keymgmt_lib.c to
keym

Reorganize the internal evp_keymgmt functions

Some of the evp_keymgmt_ functions are just wrappers around the
EVP_KEYMGMT function pointers. We move those from keymgmt_lib.c to
keymgmt_meth.c.

Other evp_keymgmt_ functions are utility functions to help the rest of
the EVP functions. Since their names are easily confused with the
functions that were moved to keymgmt_meth.c, we rename them so they
all start with evp_keymgmt_util_.

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 DH key exchange to fips provider

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

EVP: clear error when falling back from failed EVP_KEYMGMT_fetch()

Since we're falling back to legacy, this isn't an error any more.
Among others the failed EVP_KEYMGMT_fetch() error sha

EVP: clear error when falling back from failed EVP_KEYMGMT_fetch()

Since we're falling back to legacy, this isn't an error any more.
Among others the failed EVP_KEYMGMT_fetch() error shadows other errors
produced by the legacy code, which disrupts our test/evp_test runs.

We use the error stack mark to restore the error stack just right,
i.e. ERR_set_mark(), ERR_clear_last_mark() and ERR_pop_to_mark()

Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/10803)

show more ...

EVP: Add evp_pkey_make_provided() and refactor around it

The code to ensure that an EVP_PKEY is exported to providers is
repeated all over the place, enough that copying it again has the

EVP: Add evp_pkey_make_provided() and refactor around it

The code to ensure that an EVP_PKEY is exported to providers is
repeated all over the place, enough that copying it again has the
usual future hazards with code copying.

Instead, we refactor that code into one function,
evp_pkey_make_provided(), and make sure to use that everywhere.
It relies on the creation of EVP_PKEY_CTX to figure out facts about
the input key, should it need to.

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

show more ...

Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods too

These functions would only handle provided methods, but there are
cases where the caller just passes along a recei

Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods too

These functions would only handle provided methods, but there are
cases where the caller just passes along a received method without
knowing the underlying method tech, so might pass along a legacy
method. We therefore need to have them handle this case as well so
they don't cause any unnecessary surprises.

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

show more ...

EVP: Adapt KEYEXCH, SIGNATURE and ASYM_CIPHER to handle key types better

The adaptation is to handle the case when key types and operations
that use these keys have different names. For

EVP: Adapt KEYEXCH, SIGNATURE and ASYM_CIPHER to handle key types better

The adaptation is to handle the case when key types and operations
that use these keys have different names. For example, EC keys can be
used for ECDSA and ECDH.

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

show more ...

EVP: If a key can't be exported to provider, fallback to legacy

Currently, the operations that do try to export a legacy key to
providers will fail if the export failed. It makes more s

EVP: If a key can't be exported to provider, fallback to legacy

Currently, the operations that do try to export a legacy key to
providers will fail if the export failed. It makes more sense to
simply use the legacy method instead, as a fallback for things not
being implemented (yet) in a provider.

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

show more ...