Rework how our providers are built

We put almost everything in these internal static libraries:

libcommon Block building code that can be used by all

Rework how our providers are built

We put almost everything in these internal static libraries:

libcommon Block building code that can be used by all
our implementations, legacy and non-legacy
alike.
libimplementations All non-legacy algorithm implementations and
only them. All the code that ends up here is
agnostic to the definitions of FIPS_MODE.
liblegacy All legacy implementations.

libnonfips Support code for the algorithm implementations.
Built with FIPS_MODE undefined. Any code that
checks that FIPS_MODE isn't defined must end
up in this library.
libfips Support code for the algorithm implementations.
Built with FIPS_MODE defined. Any code that
checks that FIPS_MODE is defined must end up
in this library.

The FIPS provider module is built from providers/fips/*.c and linked
with libimplementations, libcommon and libfips.

The Legacy provider module is built from providers/legacy/*.c and
linked with liblegacy, libcommon and libcrypto.
If module building is disabled, the object files from liblegacy and
libcommon are added to libcrypto and the Legacy provider becomes a
built-in provider.

The Default provider module is built-in, so it ends up being linked
with libimplementations, libcommon and libnonfips. For libcrypto in
form of static library, the object files from those other libraries
are simply being added to libcrypto.

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

show more ...

Move MD5-SHA1 digest completely to the default provider

This leaves minimal implementations of EVP_md5_sha1, which is now only
there to provide a name for implicit fetches.

Revi

Move MD5-SHA1 digest completely to the default provider

This leaves minimal implementations of EVP_md5_sha1, which is now only
there to provide a name for implicit fetches.

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

show more ...

Move all SHA digests completely to the default provider

This leaves minimal implementations of EVP_sha* and EVP_shake*, which
is now only there to provide a name for implicit fetches.

Move all SHA digests completely to the default provider

This leaves minimal implementations of EVP_sha* and EVP_shake*, which
is now only there to provide a name for implicit fetches.

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

show more ...

KDF/PRF updates to libcrypto

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

Include mac_meth and mac_lib in the FIPS provider

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

Remove init of MACs from EVP

Now that all our MACs have moved to the default provider, we let it
take over completely

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-b

Remove init of MACs from EVP

Now that all our MACs have moved to the default provider, we let it
take over completely

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

show more ...

Prepare EVP_MAC infrastructure for moving all MACs to providers

Quite a few adaptations are needed, most prominently the added code
to allow provider based MACs.

As part of this

Prepare EVP_MAC infrastructure for moving all MACs to providers

Quite a few adaptations are needed, most prominently the added code
to allow provider based MACs.

As part of this, all the old information functions are gone, except
for EVP_MAC_name(). Some of them will reappear later, for example
EVP_MAC_do_all() in some form.

MACs by EVP_PKEY was particularly difficult to deal with, as they
need to allocate and deallocate EVP_MAC_CTXs "under the hood", and
thereby implicitly fetch the corresponding EVP_MAC. This means that
EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count
may need to be incremented and decremented as part of the allocation
or deallocation of the EVP_MAC_CTX. It may be that other provider
based EVP operation types may need to be handled in a similar manner.

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

show more ...

Add evp_keymgmt_export_to_provider(), for key transfer between providers

This function is used to transport private key materia from whatever
is already attached to the EVP_PKEY to the n

Add evp_keymgmt_export_to_provider(), for key transfer between providers

This function is used to transport private key materia from whatever
is already attached to the EVP_PKEY to the new provider, using key
data export and import functionality.

If a legacy lower level key has been assigned to the EVP_PKEY, we use
its data to create a provider side key, and thereby have a bridge
between old style public key types and the EVP_PKEY on providers.

If successful, this function returns a reference to the appropriate
provider side data for the key.

This can be used by any operation that wants to use this key.

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

show more ...

Add basic EVP_KEYMGMT API and libcrypto <-> provider interface

The idea with the key management "operation" is to support the
following set of functionality:

- Key domain parame

Add basic EVP_KEYMGMT API and libcrypto <-> provider interface

The idea with the key management "operation" is to support the
following set of functionality:

- Key domain parameter generation
- Key domain parameter import
- Key domain parameter export

- Key generation
- Key import
- Key export
- Key loading (HSM / hidden key support)

With that set of function, we can support handling domain parameters
on one provider, key handling on another, and key usage on a third,
with transparent export / import of applicable data. Of course, if a
provider doesn't offer export / import functionality, then all
operations surrounding a key must be performed with the same
provider.

This method also avoids having to do anything special with legacy
assignment of libcrypto key structures, i.e. EVP_PKEY_assign_RSA().
They will simply be used as keys to be exported from whenever they are
used with provider based operations.

This change only adds the EVP_KEYMGMT API and the libcrypto <->
provider interface. Further changes will integrate them into existing
libcrypto functionality.

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

show more ...

Make the EVP Key Exchange code provider aware

We introduce a new EVP_KEYEXCH type to represent key exchange algorithms
and refactor the existing code to use it where available.

Make the EVP Key Exchange code provider aware

We introduce a new EVP_KEYEXCH type to represent key exchange algorithms
and refactor the existing code to use it where available.

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

show more ...

Adapt diverse EVP_CIPHER functions to use get_params and set_params interfaces

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merg

Adapt diverse EVP_CIPHER functions to use get_params and set_params interfaces

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

show more ...

Use variables in build.info files where it's worth the while

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

Make some EVP code available from within the FIPS module

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

Added EVP_KDF (similiar to the EVP_MAC)

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openss

Added EVP_KDF (similiar to the EVP_MAC)

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

show more ...

Add generic EVP method fetcher

This is an interface between Core dispatch table fetching and
EVP_{method}_fetch(). All that's needed from the diverse method
fetchers are the functio

Add generic EVP method fetcher

This is an interface between Core dispatch table fetching and
EVP_{method}_fetch(). All that's needed from the diverse method
fetchers are the functions to create a method structure from a
dispatch table, a function that ups the method reference counter and a
function to free the method (in case of failure).

This routine is internal to the EVP API andis therefore only made
accessible within crypto/evp, by including evp_locl.h

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

show more ...

Added new EVP/KDF API.
Changed PKEY/KDF API to call the new API.
Added wrappers for PKCS5_PBKDF2_HMAC() and EVP_PBE_scrypt() to call the new EVP KDF APIs.
Documentation updated.

Added new EVP/KDF API.
Changed PKEY/KDF API to call the new API.
Added wrappers for PKCS5_PBKDF2_HMAC() and EVP_PBE_scrypt() to call the new EVP KDF APIs.
Documentation updated.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6674)

show more ...

Add generic EVP_PKEY_METHOD for EVP_MACs

The MAC EVP_PKEY implementations are currently implemented for each
MAC. However, with the EVP_MAC API, only one such implementation is
need

Add generic EVP_PKEY_METHOD for EVP_MACs

The MAC EVP_PKEY implementations are currently implemented for each
MAC. However, with the EVP_MAC API, only one such implementation is
needed.

This implementation takes into account the differences between HMAC
and CMAC implementations, and observes that all other current MAC
implementations seem to follow the HMAC model.

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

show more ...

Add automatic initializations support for EVP_MAC objects

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

Add EVP_MAC API

We currently implement EVP MAC methods as EVP_PKEY methods. This
change creates a separate EVP API for MACs, to replace the current
EVP_PKEY ones.

A note ab

Add EVP_MAC API

We currently implement EVP MAC methods as EVP_PKEY methods. This
change creates a separate EVP API for MACs, to replace the current
EVP_PKEY ones.

A note about this EVP API and how it interfaces with underlying MAC
implementations:

Other EVP APIs pass the EVP API context down to implementations, and
it can be observed that the implementations use the pointer to their
own private data almost exclusively. The EVP_MAC API deviates from
that pattern by passing the pointer to the implementation's private
data directly, and thereby deny the implementations access to the
EVP_MAC context structure. This change is made to provide a clearer
separation between the EVP library itself and the implementations of
its supported algorithm classes.

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

show more ...

s390x assembly pack: add KIMD/KLMD code path for sha3/shake

Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich

s390x assembly pack: add KIMD/KLMD code path for sha3/shake

Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5935)

show more ...

SM3: restructure to EVP internal and update doc to right location

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https:

SM3: restructure to EVP internal and update doc to right location

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4616)

show more ...

SM3: Add SM3 hash function

SM3 is a secure hash function which is part of the Chinese
"Commercial Cryptography" suite of algorithms which use is
required for certain commercial appli

SM3: Add SM3 hash function

SM3 is a secure hash function which is part of the Chinese
"Commercial Cryptography" suite of algorithms which use is
required for certain commercial applications in China.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4616)

show more ...

SM4: Add SM4 block cipher to EVP

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull

SM4: Add SM4 block cipher to EVP

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4552)

show more ...

Implement Aria GCM/CCM Modes and TLS cipher suites

AEAD cipher mode implementation is based on that used for AES:

https://tools.ietf.org/html/rfc5116

TLS GCM cipher suite

Implement Aria GCM/CCM Modes and TLS cipher suites

AEAD cipher mode implementation is based on that used for AES:

https://tools.ietf.org/html/rfc5116

TLS GCM cipher suites as specified in:

https://tools.ietf.org/html/rfc6209

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4287)

show more ...

Rename crypto/evp/scrypt.c to crypto/evp/pbe_scrypt.c

There already is a scrypt.c in crypto/kdf/, both becoming script.o or
script.obj. With some linkers, the same object files name mor

Rename crypto/evp/scrypt.c to crypto/evp/pbe_scrypt.c

There already is a scrypt.c in crypto/kdf/, both becoming script.o or
script.obj. With some linkers, the same object files name more than
once means one of them is dropped, either when building shared
libraries or when building executables from static libraries.

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4164)

show more ...