The KDF bridge is now done provider side so the old EVP_PKEY_METHODS for
this are no longer required.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12573)

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: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)

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

Don't wrap conditionally-compiled files in global ifndef tests.
Instead, test if the feature is disabled and, if so, do not
compile it.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11263)

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

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

This affects the following function, which can now deal with provider
side keys:

- EVP_SealInit()
- EVP_OpenInit()
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10808)

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

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

Macros have been added to generate the simple legacy methods.
Engines and EVP_MD_METH_get methods still require access to the old legacy methods,
so they needed to be added back in.
They may only be removed after engines are deprecated and removed.
Removed some unnecessary #includes and #ifndef guards (which are done in build.info instead).
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10602)

We modify the build.info file to exclude the legacy_blake2.c file in
the event that blake2 support has been disabled.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10425)

This leaves minimal implementations of EVP_blake2b512 and EVP_blake2s256,
that are now only there to provide a name for implicit fetches.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9075)

This leaves minimal implementations of EVP_md2, EVP_md4, EVP_md5 and
EVP_mdc2, that are now only there to provide a name for implicit fetches.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10164)

Prior to OpenSSL 3.0 EVP_Digest[Sign|Verify|Update were just macros for
EVP_DigestUpdate. They are now separate functions. Unfortunately some
code assumes that EVP_Digest[Sign|Verify]Update is interchangeable with
EVP_DigestUpdate. For example the dgst app uses an MD bio which always
calls EVP_DigestUpdate(). However the dgst app supports signing instead
of digesting and may initialise with EVP_DigestSignInit_ex() instead of
just EVP_DigestInit().

We now detect these differences and redirect to the correct function
where appropriate.

Fixes #10114
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10116)

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: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)

This leaves minimal implementations of EVP_md5_sha1, which is now only
there to provide a name for implicit fetches.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9076)

This leaves minimal implementations of EVP_sha* and EVP_shake*, which
is now only there to provide a name for implicit fetches.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10059)

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

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

Now that all our MACs have moved to the default provider, we let it
take over completely
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8877)

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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8877)

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: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9312)

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: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9312)

We introduce a new EVP_KEYEXCH type to represent key exchange algorithms
and refactor the existing code to use it where available.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9266)

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

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

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

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

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: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8341)

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: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6674)

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: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)

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

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: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)

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

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

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: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4616)

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

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/rfc6209Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4287)

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: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4164)

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