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: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11148)

This includes legacy PSS controls to params conversion, and an attempt
to generalise the parameter names when they are suitable for more than
one operation.

Also added crypto/rsa/rsa_aid.c, containing proper AlgorithmIdentifiers
for known RSA+hash function combinations.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10557)

When converting legacy controls to OSSL_PARAMs, return the unsupported -2
value correctly.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11049)

The extra argument is a integer pointer and is optional.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11049)

Use of the low level DH functions has been informally discouraged for a
long time.  We now formally deprecate them.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11024)

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

It is better, safer and smaller to let the library routine handle the
strlen(3) call.

Added a note to the documentation suggesting this.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11019)

It turns out this was never necessary, as the implementation should
always check the default digest size anyway.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10947)

This function did a bit too much in terms of central control, actually
more so than the legacy counterpart, where all the string processing
is done in the diverse *_pmeth.c.  Furthermore, there was no room
whatsoever for control keys that libcrypto isn't centrally aware of.

This function is changed to simply translating keys and values to
OSSL_PARAM form and then sent on their merry way to the provider
implementations through EVP_PKEY_CTX_set_params().  It translates
selected well known legacy names to their core name counterpart, and
that's as far as centralized control should extend.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10947)

The code was calling EVP_MD_meth_free which is incorrect.  It should call
EVP_MD_free.  It happened to work but by luck rather than design.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10973)

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

The function EVP_PKEY_CTX_new_from_pkey() infers the name of the
algorithm to fetch from the EVP_PKEY that has been supplied as an
argument. But there was no way to specify properties to be used during
that fetch.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10926)

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

The fix inroduced in #10758 was rolled back by accident.
Restoring it.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10839)

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

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: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10647)

For the implementation of EVP_PKEY_CTX_new(), we determined if an
EVP_PKEY wass legacy or not by looking at 'pkey->pkey.ptr'.  It turns
out that this code could get an unassigned EVP_PKEY, with that pointer
being NULL, and the determination proven incorrect.

The check now looks at 'pkey->ameth' instead.

Fixes #10704
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/10758)

The case when EVP_PKEY_CTX_new() is called with a provided EVP_PKEY
(no legacy data) wasn't handled properly.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10618)

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10388)

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

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

Now that we have an EVP namemap containing all aliases that providers
know about for any given algorithm, it is possible that an application
attempts to look up a digest or a cipher via EVP_get_digestbyname() or
EVP_get_cipherbyname() with an algorithm name that is unknown to the
legacy method database. Therefore we extend those functions to
additionally check the aliases in the namemap when searching for a
method in the event that our initial lookup attempt fails.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10324)

Because the algorithm to use is decided already when creating an
EVP_PKEY_CTX regardless of how it was created, it turns out that it's
unnecessary to provide the KEYEXCH method explicitly, and rather
always have it be fetched implicitly.

This means fewer changes for applications that want to use new key
exchange algorithms / implementations.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10305)

With provided algorithms, the library context is ever present, so of
course it should be specified alongside the algorithm name and
property query string.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10308)

There is a vagueness around how the provider data (algorithm name and
property query string) is initialized in the presence of an engine.
This change modifies this slightly so that the algorithm name for use
with providers is never set if the initilization was given an engine.

This makes it easier for other functions to simply check ctx->algorithm
to see if the context is meant to be used for strictly legacy stuff or
not.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10308)

Otherwise, should this function be called more than once on the same
EVP_PKEY_CTX, we get double free issues.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10292)

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

This works as much as possible EVP_PKEY_CTX_new_id(), except it takes
data that's relevant for providers, algorithm name and property query
string instead of NID and engine.

Additionally, if EVP_PKEY_CTX_new() or EVP_PKEY_CTX_new_id() was
called, the algorithm name in the EVP_PKEY context will be set to the
short name of the given NID (explicit or the one of the given
EVP_PKEY), thereby giving an easier transition from legacy methods to
provided methods.

The intent is that operations will use this information to fetch
provider methods implicitly as needed.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10184)

Also added blanks lines after declarations in a couple of places.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9916)

Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like

  '*_lcl.h', '*_local.h', or '*_int.h'

This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)

Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:

While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.

To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:

  #include "internal/file.h"      # located in 'include/internal'
  #include "internal/file_int.h"  # located in 'crypto/include/internal'

This commit moves the private crypto headers from

  'crypto/include/internal'  to  'include/crypto'

As a result, the include directives become unambiguous

  #include "internal/file.h"       # located in 'include/internal'
  #include "crypto/file.h"         # located in 'include/crypto'

hence the superfluous '_int.h' suffixes can be stripped.

The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)

using PCC and KDSA instructions.
Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10004)

An EVP_PKEY can be used for multiple different algorithm operations.
Only one can be used at a time, so we move those into a union.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9753)

We add new functions for getting parameters and discovering the gettable
and settable parameters. We also make EVP_PKEY_CTX_get_signature_md() a
function and implement it in terms of the new functions.

This enables applications to discover the set of parameters that are
supported for a given algorithm implementation.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9753)

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

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

This makes EVP_PKEY_sign and EVP_PKEY_sign_init provider aware. It
also introduces the new type EVP_SIGNATURE to represent signature
algorithms. This also automatically makes the EVP_Sign* APIs provider
aware because they use EVP_Digest* (which is already provider aware)
and EVP_PKEY_sign(_init) under the covers.

At this stage there are no signature algorithms in any providers. That
will come in the following commits.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9753)

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

The biggest part in this was to move the key->param builder from EVP
to the DH ASN.1 method, and to implement the KEYMGMT support in the
provider DH.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9394)

This affects all its callers: EVP_PKEY_CTX_new(), EVP_PKEY_CTX_new_id().
They are now possible to called with "zero" values, i.e.:

    EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new(NULL, NULL);

or

    EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(0, NULL);

This is suitable for provider use, as the key functionality is tied
with its keys, and the operation time is determined by the init
functions the EVP_PKEY_CTX is used with.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9312)