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

rand: reference count the EVP_RAND contexts.

This is required before the RAND/DRBG framework can be made user mutable.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged

rand: reference count the EVP_RAND contexts.

This is required before the RAND/DRBG framework can be made user mutable.

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

show more ...

Add KEM (Key encapsulation mechanism) support to providers

SP800-56Br2 requires support for the RSA primitives for RSASVE generate and recover.
As these are simple KEM operations another

Add KEM (Key encapsulation mechanism) support to providers

SP800-56Br2 requires support for the RSA primitives for RSASVE generate and recover.
As these are simple KEM operations another operation type has been added that can support future extensions.

Added public functions EVP_PKEY_encapsulate_init(), EVP_PKEY_encapsulate(), EVP_PKEY_decapsulate_init() and EVP_PKEY_decapsulate()
Added EVP_KEM_* functions.
Added OSSL_FUNC_kem_* dispatch functions

Added EVP_PKEY_CTX_set_kem_op() so that different types of KEM can be added in the future. This value must currently be set to
"RSASVE" after EVP_PKEY_encapsulate_init() & EVP_PKEY_decapsulate_init() as there is no default value.
This allows the existing RSA key types, keymanagers, and encoders to be used with the encapsulation operations.

The design of the public API's resulted from contributions from @romen & @levitte.

Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12750)

show more ...

Add CMS AuthEnvelopedData with AES-GCM support

Add the AuthEnvelopedData as defined in RFC 5083 with AES-GCM
parameter as defined in RFC 5084.

Reviewed-by: Shane Lontis <shane.l

Add CMS AuthEnvelopedData with AES-GCM support

Add the AuthEnvelopedData as defined in RFC 5083 with AES-GCM
parameter as defined in RFC 5084.

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

show more ...

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

KEYMGMT: Add key loading function OSSL_FUNC_keymgmt_load()

This function is used to create a keydata for a key that libcrypto
only has a reference to.

This introduces provider r

KEYMGMT: Add key loading function OSSL_FUNC_keymgmt_load()

This function is used to create a keydata for a key that libcrypto
only has a reference to.

This introduces provider references, the contents which only the
provider know how to interpret. Outside of the provider, this is just
an array of bytes.

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

show more ...

rand: avoid caching RNG parameters.

The strength and max_length DRBG parameters were being cached in the EVP_RAND
layer. This commit removes the caching.

Reviewed-by: Matthias

rand: avoid caching RNG parameters.

The strength and max_length DRBG parameters were being cached in the EVP_RAND
layer. This commit removes the caching.

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

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 <openssl/core_numbers.h> -> <openssl/core_dispatch.h>

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

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

rand: core APIs for provider friendly random.

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

Remove gen_get_params & gen_gettable_params from keygen operation

EVP_PKEY_CTX_gettable_params() was missing code for the keygen operation.
After adding it it was noticed that it is prob

Remove gen_get_params & gen_gettable_params from keygen operation

EVP_PKEY_CTX_gettable_params() was missing code for the keygen operation.
After adding it it was noticed that it is probably not required for this type, so instead
the gen_get_params and gen_gettable_params have been remnoved from the provider interface.
gen_get_params was only implemented for ec to get the curve name. This seems redundant
since normally you would set parameters into the keygen_init() and then generate a key.
Normally you would expect to extract data from the key - not the object that we just set up
to do the keygen.

Added a simple settable and gettable test into a test that does keygen.

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

show more ...

Update copyright year

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

KEYMGMT: Add functions to get param/key generation parameters

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.

KEYMGMT: Add functions to get param/key generation parameters

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/11328)

show more ...

CORE: Add the key object generator libcrypto<->provider interface

We introduce these dispatched functions:

- OP_keymgmt_gen_init() to initialize the key object generation.
-

CORE: Add the key object generator libcrypto<->provider interface

We introduce these dispatched functions:

- OP_keymgmt_gen_init() to initialize the key object generation.
- OP_keymgmt_gen_set_template() to set a template for key object
generation. The template is another key object, for example one
with domain parameters.
- OP_keymgmt_gen_set_params() to set other key object generation
parameters.
- OP_keymgmt_gen_settable_params() to find out what settable
parameters there are.
- OP_keymgmt_gen() to perform the key object generation.
- OP_keymgmt_gen_cleanup() to clean up the key object generation.

Internal function for easy and consistent use of these ddispatched
functions are added.

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

show more ...

Implement provider support for Ed25519 annd Ed448

At the moment we only provider support for these algorithms in the default
provider. These algorithms only support "one shot" EVP_Digest

Implement provider support for Ed25519 annd Ed448

At the moment we only provider support for these algorithms in the default
provider. These algorithms only support "one shot" EVP_DigestSign() and
EVP_DigestVerify() as per the existing libcrypto versions.

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

show more ...

KEYMGMT: Add a keydata copy function

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

KEYMGMT: Add a keydata matching function

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

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

Add RSA key validation to default provider

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

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

EVP: make EVP_PKEY_{bits,security_bits,size} work with provider only keys

These functions relied entirely on the presence of 'pkey->pmeth',
which is NULL on provider only keys. This add

EVP: make EVP_PKEY_{bits,security_bits,size} work with provider only keys

These functions relied entirely on the presence of 'pkey->pmeth',
which is NULL on provider only keys. This adds an interface to get
domparam and key data from a provider, given corresponding provider
data (the actual domparam or key).

The retrieved data is cached in the EVP_PKEY structure (lending the
idea from provided EVP_CIPHER).

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

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