summaryrefslogtreecommitdiffstats
path: root/include/crypto/evp.h
AgeCommit message (Collapse)Author
2020-05-23Re-introduce legacy EVP_PKEY types for provided keysRichard Levitte
EVP_PKEYs with provider side internal keys got the key type EVP_PKEY_NONE. This turned out to be too disruptive, so we try instead to find a matching EVP_PKEY_ASN1_METHOD and use whatever EVP_PKEY type it uses. To make internal coding easier, we introduce a few internal macros to distinguish what can be expected from a EVP_PKEY: - evp_pkey_is_blank(), to detect an unassigned EVP_PKEY. - evp_pkey_is_typed(), to detect that an EVP_PKEY has been assigned a type, which may be an old style type number or a EVP_KEYMGMT method. - evp_pkey_is_assigned(), to detect that an EVP_PKEY has been assigned an key value. - evp_pkey_is_legacy(), to detect that the internal EVP_PKEY key is a legacy one, i.e. will be handled via an EVP_PKEY_ASN1_METHOD and an EVP_PKEY_METHOD. - evp_pkey_is_provided(), to detect that the internal EVP_PKEY key is a provider side one, i.e. will be handdled via an EVP_KEYMGMT and other provider methods. This also introduces EVP_PKEY_KEYMGMT, to indicate that this EVP_PKEY contains a provider side key for which there are no known EVP_PKEY_ASN1_METHODs or EVP_PKEY_METHODs, i.e. these can only be handled via EVP_KEYMGMT and other provider methods. Fixes #11823 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11913)
2020-05-07Remove gen_get_params & gen_gettable_params from keygen operationShane Lontis
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)
2020-04-28Rename FIPS_MODE to FIPS_MODULERichard Levitte
This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-23Update copyright yearMatt Caswell
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11616)
2020-04-23EVP: add internal evp_keymgmt_util_get_deflt_digest_name() and use itRichard Levitte
evp_keymgmt_util_get_deflt_digest_name() is a refactor of the provider side key part of EVP_PKEY_get_default_digest_name(), that takes EVP_KEYMGMT and provider keydata pointers instead of an EVP_PKEY pointer. We also ensure that it uses SN_undef as the default name if the provider implementation gave us an empty string, since this is what EVP_PKEY_get_default_digest_name() responds when getting the digest name via a EVP_PKEY_ASN1_METHOD ctrl call that returns NID_undef. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11576)
2020-04-15Teach d2i_PrivateKey et al about libctxMatt Caswell
The Ed448 private key decoding makes algorithm fetches. Therefore we teach d2i_PrivateKey et al about libctx and make sure it is passed through the layers. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11494)
2020-04-15KEYMGMT: Add functions to get param/key generation parametersRichard Levitte
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/11328)
2020-04-14Add ex_data to EVP_PKEY.Aaron Thompson
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/11515)
2020-03-25EVP: Downgrade keys rather than upgradeRichard Levitte
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: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-25EVP: Clarify the states of an EVP_PKEYRichard Levitte
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: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11375)
2020-03-21EVP: fetch the EVP_KEYMGMT earlierRichard Levitte
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: Paul Yang <kaishen.yy@antfin.com> (Merged from https://github.com/openssl/openssl/pull/11343)
2020-03-15EVP: Don't call digest_custom() quite so earlyRichard Levitte
A huge problem with calling digest_custom() already in the initialization of DigestSign, DigestVerify etc, is that it force all callers to know that certain controls must be performed before Init and the rest after. This has lead to quite interesting hacks in our own openssl app, where the SM2 ID had to get special treatment instead of just being another sign option or verification option among others. This change moves the call of digest_custom() to the Update and Final functions, to be done exactly once, subject to a flag that's set in the Init function. Seeing to the process of data, through these operations, this makes no difference at all. Seeing to making it possible to perform all controls after the Init call, this makes a huge difference. Fixes #11293 Reviewed-by: Paul Yang <kaishen.yy@antfin.com> (Merged from https://github.com/openssl/openssl/pull/11302)
2020-03-12EVP: Add new domparams and key generation functionalityRichard Levitte
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: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10289)
2020-03-12CORE: Add the key object generator libcrypto<->provider interfaceRichard Levitte
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)
2020-03-02EVP: Add support for copying provided EVP_PKEYsRichard Levitte
This adds evp_keymgmt_util_copy() and affects EVP_PKEY_copy_parameters() Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11158)
2020-03-02KEYMGMT: Add a keydata copy functionRichard Levitte
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11158)
2020-03-02EVP: Add support for comparing provided EVP_PKEYsRichard Levitte
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: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11158)
2020-03-02KEYMGMT: Add a keydata matching functionRichard Levitte
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11158)
2020-03-02EVP: Adapt EVP_PKEY_missing_parameters() for provider keysRichard Levitte
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11158)
2020-02-29EVP: Add evp_pkey_upgrade_to_provider(), for EVP_PKEY upgradesRichard Levitte
This function "upgrades" a key from a legacy key container to a provider side key container. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-29Rethink the EVP_PKEY cache of provider side keysRichard Levitte
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: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11148)
2020-02-22Refactor evp_pkey_make_provided() to do legacy to provider exportRichard Levitte
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)
2020-02-18[PROV][KMGMT][KEXCH][EC] Implement EC keymgtm and ECDHNicola Tuveri
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)
2020-02-11Implement a stricter ECX_KEY typeMatt Caswell
Add ref counting and control how we allocate storage for the private key. We will need this type in following commits where we move the ecx code to be provider aware. Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10964)
2020-02-07Redesign the KEYMGMT libcrypto <-> provider interface - the basicsRichard Levitte
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)
2020-02-07Reorganize the internal evp_keymgmt functionsRichard Levitte
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: 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)
2020-01-29Add RSA key validation to default providerShane Lontis
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10780)
2020-01-17EVP: make EVP_PKEY_{bits,security_bits,size} work with provider only keysRichard Levitte
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)
2020-01-12Add dsa signature alg to fips providerShane Lontis
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10615)
2020-01-09EVP: Adapt KEYEXCH, SIGNATURE and ASYM_CIPHER to handle key types betterRichard Levitte
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: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10647)
2019-11-14CORE & PROV: make export of key data leaner through callbackRichard Levitte
Exporting data from a provider owned domainparams or key is quite an ordeal, with having to figure out what parameter keys an implementation supports, call the export function a first time to find out how large each parameter buffer must be, allocate the necessary space for it, and call the export function again. So how about letting the export function build up the key data params and call back with that? This change implements exactly such a mechanism. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10414)
2019-11-14Implement provider support for Asym CiphersMatt Caswell
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10152)
2019-11-07Add EVP functionality to create domain params and keys by user dataRichard Levitte
This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-11-06Ensure EVP_get_digestbyname() and EVP_get_cipherbyname() know all aliasesMatt Caswell
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: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10324)
2019-11-05EVP: Make the KEYEXCH implementation leanerRichard Levitte
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: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10305)
2019-11-03Change EVP_PKEY_CTX_new_provided() to take a library context too.Richard Levitte
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: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10308)
2019-10-17PKEY: adapt the export_to_provider funtions to handle domain params tooRichard Levitte
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10169)
2019-10-16Add EVP_PKEY_CTX_new_provided()Richard Levitte
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: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10184)
2019-10-14KDF: clean away old EVP_KDF declarationsRichard Levitte
They were left-overs from when we still had the legacy KDF implementation Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10170)
2019-09-28Reorganize private crypto header filesDr. Matthias St. Pierre
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: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-11 12:43:49 +0000