Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/11515)

The EC export_to function calls EC_POINT_point2buf that can later
generate a random number in some circumstances. Therefore we pass in a
BN_CTX associated with the library context. This means we have to change
the export_to function signature to accept the library context.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11493)

libssl code uses EVP_PKEY_get0_EC_KEY() to extract certain basic data
from the EC_KEY.  We replace that with internal EVP_PKEY functions.

This may or may not be refactored later on.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11358)

EVP_PKEY_is_a() is the provider side key checking function corresponding
to checking EVP_PKEY_id() or an EVP_PKEY against macros like EVP_PKEY_EC.
It also works with legacy internal keys.

We also add a warning indoc/man3/EVP_PKEY_set1_RSA.pod regarding the
reliability of certain functions that only understand legacy keys.

Finally, we take the opportunity to clean up doc/man3/EVP_PKEY_set1_RSA.pod
to better conform with man-page layout norms, see man-pages(7) on Linux.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11358)

Currently only RSA, EC and ECX are supported (DH and DSA need to be added to the keygen
PR's seperately because the fields supported have changed significantly).

The API's require the keys to be provider based.

Made the keymanagement export and get_params functions share the same code by supplying
support functions that work for both a OSSL_PARAM_BLD as well as a OSSL_PARAM[].
This approach means that complex code is not required to build an
empty OSSL_PARAM[] with the correct sized fields before then doing a second
pass to populate the array.

The RSA factor arrays have been changed to use unique key names to simplify the interface
needed by the user.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11365)

Provider KEYMGMT functions can handle domain parameters as well as
"other" parameters (the cofactor mode flag in ECC keys is one of
those).  The public EVP functions EVP_PKEY_copy_parameters(),
EVP_PKEY_missing_parameters(), EVP_PKEY_cmp_parameters() and
EVP_PKEY_cmp() tried to handle all parameters, but looking back at
EVP_PKEY_ASN1_METHOD code (especially crypto/ec/ec_ameth.c), it turns
out that they only need to concern themselves with domain parameters.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11375)

Upgrading EVP_PKEYs from containing legacy keys to containing provider
side keys proved to be risky, with a number of unpleasant corner
cases, and with functions like EVP_PKEY_get0_DSA() failing
unexpectedly.

We therefore change course, and instead of upgrading legacy internal
keys to provider side internal keys, we downgrade provider side
internal keys to legacy ones.  To be able to do this, we add
|import_from| and make it a callback function designed for
evp_keymgmt_export().

This means that evp_pkey_upgrade_to_provider() is replaced with
evp_pkey_downgrade().

EVP_PKEY_copy_parameters() is the most deeply affected function of
this change.

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

This function intialises an EVP_PKEY to contain a provider side internal
key.

We take the opportunity to also document the older EVP_PKEY_set_type()
and EVP_PKEY_set_type_str().
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11375)

EVP_PKEY is rather complex, even before provider side keys entered the
stage.
You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE),
keys that had been assigned a type but no data (pk->pkey.ptr == NULL),
and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL).

For provider side keys, the corresponding states weren't well defined,
and the code didn't quite account for all the possibilities.

We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so
they don't exist at all in the FIPS module.

Most of all, code needs to adapt to the case where an EVP_PKEY's
|keymgmt| is non-NULL, but its |keydata| is NULL.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11375)

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: NPaul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/11343)

The following functions are added:

EVP_PKEY_gen_set_params(), replacing the older EVP_PKEY_CTX_ctrl()
EVP_PKEY_gen(), replacing both EVP_PKEY_keygen() and EVP_PKEY_paramgen()

These functions are made to work together with already existing domparams
and key generation functionality: EVP_PKEY_CTX_new_provided(),
EVP_PKEY_paramgen_init(), EVP_PKEY_keygen_init(), etc.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10289)

This adds evp_keymgmt_util_copy() and affects EVP_PKEY_copy_parameters()
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11158)

This adds evp_keymgmt_util_match() and affects EVP_PKEY_cmp() and
EVP_PKEY_cmp_parameters().

The word 'match' was used for the new routines because many associate
'cmp' with comparison functions that allows sorting, i.e. return -1, 0
or 1 depending on the order in which the two compared elements should
be sorted.  EVP_PKEY_cmp() and EVP_PKEY_cmp_parameters() don't quite
do that.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11158)

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

This function "upgrades" a key from a legacy key container to a
provider side key container.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11148)

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)

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

Use of the low level DSA functions has been informally discouraged for a
long time. We now formally deprecate them.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10977)

Recent SM2 related changes were not properly guarded with OPENSSL_NO_EC
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/11029)

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

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

This means that when loaded or created, EC EVP_PKEYs with the SM2
curve will be regarded as EVP_PKEY_SM2 type keys by default.
Applications are no longer forced to check and fix this.

It's still possible, for those who want this, to set the key type to
EVP_PKEY_EC and thereby run the normal EC computations with the SM2
curve.  This has to be done explicitly.
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/10942)

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)

It is the provider version of EVP_PKEY_get_default_digest_nid().  We make
sure to use it in the non-legacy section of do_sigver_init() (internal
implementation for EVP_DigestSignInit() and EVP_DigestVerifyInit())
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10824)

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

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: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/10778)

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

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

We take the opportunity to refactor EVP_PKEY_print_public,
EVP_PKEY_print_private, EVP_PKEY_print_params to lessen the amount of
code copying.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10531)

OpenSSL supports both PKCS#3 and X9.42 DH keys. By default we use PKCS#3
keys. The function `EVP_PKEY_set1_DH` was assuming that the supplied DH
key was a PKCS#3 key. It should detect what type of key it is and assign
the correct type as appropriate.

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

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

Check for NULL and return error if so.
This can possibly be called from apps/ca.c with a NULL argument.
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/10474)

RSA-PSS keys use the same internal structure as RSA keys but do not
allow accessing it through EVP_PKEY_get0_RSA. This commit changes that
behavior.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10217)

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)

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)

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

If the passed string length is zero, the function computes the string length
from the passed string.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9760)

ENGINE_get_name() actually returns more of a long description of the
engine, whilst ENGINE_get_id() returns a shorter id.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9720)

Make sure references to ENGINE functions are appropriately guarded.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9720)

The EVP_PKEY MAC implementations had a diversity of controls that were
really the same thing.  We did reproduce that for the provider based
MACs, but are changing our minds on this.  Instead of that, we now use
one parameter name for passing the name of the underlying ciphers or
digests to a MAC implementation, "cipher" and "digest", and one
parameter name for passing the output size of the MAC, "size".

Then we leave it to the EVP_PKEY->EVP_MAC bridge to translate "md"
to "digest", and "digestsize" to "size".
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9667)