summaryrefslogtreecommitdiffstats
path: root/crypto/evp/m_sigver.c
AgeCommit message (Collapse)Author
2021-03-12evp: add params arguments to init functionsPauli
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14383)
2021-03-04do_sigver_init: Remove fallback for missing provider implementations.Tomas Mraz
We now have everything implemented in providers. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14404)
2021-02-18Update copyright yearMatt Caswell
Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14235)
2021-02-17Fix propquery handling in EVP_DigestSignInit_exPetr Gotthard
Fixes #14183. Fix the condition to detect legacy engines, so the `props` are considered even when libctx == NULL. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14188)
2020-11-13Convert all {NAME}err() in crypto/ to their corresponding ERR_raise() callRichard Levitte
This includes error reporting for libcrypto sub-libraries in surprising places. This was done using util/err-to-raise Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13318)
2020-10-15Rename OPENSSL_CTX prefix to OSSL_LIB_CTXDr. Matthias St. Pierre
Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix, e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER. The OPENSSL_CTX type stands out a little by using a different prefix. For consistency reasons, this type is renamed to OSSL_LIB_CTX. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12621)
2020-10-01EVP: use evp_pkey_ctx_is_legacy() to find what implementation to useRichard Levitte
We've had explicit checks for when to fall back to legacy code for operations that use an EVP_PKEY. Unfortunately, the checks were radically different in different spots, so we refactor that into a macro that gets used everywhere. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13043)
2020-10-01Run the withlibctx.pl scriptMatt Caswell
Automatically rename all instances of _with_libctx() to _ex() as per our coding style. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12970)
2020-09-17HMAC should work with non-provided digestsDmitry Belyavskiy
Fixes #12839 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12874)
2020-09-10Fix an EVP_MD_CTX leakMatt Caswell
If we initialise an EVP_MD_CTX with a legacy MD, and then reuse the same EVP_MD_CTX with a provided MD then we end up leaking the md_data. We need to ensure we free the md_data if we change to a provided MD. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12779)
2020-09-08EVP: Add support for delayed EVP_PKEY operation parametersRichard Levitte
They get called "delayed parameters" because they may make it to the implementation at a later time than when they're given. This currently only covers the distinguished ID, as that's the only EVP_PKEY operation parameter so far that has been possible to give before the operation has been initialized. This includes a re-implementation of EVP_PKEY_CTX_set1_id(), EVP_PKEY_CTX_get1_id(), and EVP_PKEY_CTX_get1_id_len(). Also, the more rigorous controls of keytype and optype are restored. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12789)
2020-08-29Don't require a default digest from signature algorithmsMatt Caswell
Some signature algorithms don't need a default digest, so don't fail if we don't have one. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12637)
2020-08-29Fix some EVP_MD_CTX_* functionsMatt Caswell
Fixes some issues with EVP_MD_CTX_* functions when doing EVP_DigestSign* and EVP_DigestVerify* functions. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12637)
2020-08-09Add EVP signature with libctx methods.Shane Lontis
-Added EVP_SignFinal_with_libctx() and EVP_VerifyFinal_with_libctx() -Renamed EVP_DigestSignInit_ex() and EVP_DigestVerifyInit_with_libctx() to EVP_DigestSignInit_with_libctx() and EVP_DigestVerifyInit_with_libctx() Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11884)
2020-07-30Don't fallback to legacy in DigestSignInit/DigestVerifyInit too easilyMatt Caswell
The only reason we should fallback to legacy codepaths in DigestSignInit/ DigestVerifyInit, is if we have an engine, or we have a legacy algorithm that does not (yet) have a provider based equivalent (e.g. SM2, HMAC, etc). Currently we were falling back even if we have a suitable key manager but the export of the key fails. This might be for legitimate reasons (e.g. we only have the FIPS provider, but we're trying to export a brainpool key). In those circumstances we don't want to fallback to the legacy code. Therefore we tighten then checks for falling back to legacy. Eventually this particular fallback can be removed entirely (once all legacy algorithms have provider based key managers). Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12550)
2020-05-14EVP: For SIGNATURE operations, pass the propquery earlyRichard Levitte
Instead of passing it with signature->digest_verify_init() and signature->digest_sign_init(), we pass it with signature->newctx(). This allows the digests that are indicated by RSA PSS parameters to have a useful propquery. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11710)
2020-04-30coverity 1462546 Dereference after null checkPauli
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11651)
2020-04-30coverity 1462565: Null pointer dereferencesPauli
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11651)
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: Fix EVP_Digest{Sign,Verify}Init() to handle no default digestRichard Levitte
EVP_DigestSignInit() and EVP_DigestVerifyInit() would detect if there is no default digest when using legacy (EVP_PKEY_ASN1_METHOD) implementations. However, it doesn't do that when provider side keys are used. Furthermore, because EVP_PKEY_get_default_digest_name() was used in the portion of the code that uses the provider implementation, the EVP_PKEY_ASN1_METHOD would be used if the key has one attached. This is now changed to use evp_keymgmt_util_get_deflt_digest_name() instead. Finally, we make sure to detect if the provider implementation supports the digest name parameters (default or mandatory), and returns with error if not. This is what the legacy portion of the code does. Fixes #11571 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11576)
2020-03-23Handle mdname in legacy EVP_DigestSignInit_ex codepathsMatt Caswell
Even though an application callS the new EVP_DigestSignInit_ex() function to pass an mdname by string rather than EVP_MD, we may still end up in legacy codepaths, and therefore we need to handle either mdname or EVP_MD, in both legacy and non-legacy codepaths. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11353)
2020-03-23Make it possible to easily specify a libctx for EVP_DigestSign*Matt Caswell
EVP_DigestSignInit_ex and EVP_DigestVerifyInit_ex did not provide the capability to specify an explicit OPENSSL_CTX parameter. It is still possible by explicitly setting an EVP_PKEY_CTX - but in most cases it would be much simpler to just specify it in the Init call. We add the capability to do that. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11353)
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-09EVP: Check that key methods aren't foreign when exportingRichard Levitte
The EVP_PKEY_ASN1_METHOD function export_to() must check that the key we're trying to export has a known libcrypto method, i.e. is a built in RSA_METHOD, DSA_METHOD, etc. Otherwise, the method may be defined by the calling application, by an engine, by another library, and we simply cannot know all the quirks hidden behind that method, if we have access to the key data, or much anything. Such keys are simply deemed impossible to export to provider keys, i.e. have export_to() return 0. This cascades back to functions like evp_pkey_export_to_provider() and evp_pkey_upgrade_to_provider() and their callers. In most cases, this is fine, but if these get mixed in with provider side keys in any function, that function will fail. Fixes #11179 Fixes #9915 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11193)
2020-03-09Add provider awareness of EVP_DigestSign() and EVP_DigestVerify()Matt Caswell
These "one-shot" functions are the only ones supported by Ed25519 and Ed448, so we need to ensure that libcrypto can handle provider based implementations of these functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11261)
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-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-01-23EVP: Add EVP_PKEY_get_default_digest_name() and use itRichard Levitte
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: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10824)
2020-01-21EVP: clear error when falling back from failed EVP_KEYMGMT_fetch()Richard Levitte
Since we're falling back to legacy, this isn't an error any more. Among others the failed EVP_KEYMGMT_fetch() error shadows other errors produced by the legacy code, which disrupts our test/evp_test runs. We use the error stack mark to restore the error stack just right, i.e. ERR_set_mark(), ERR_clear_last_mark() and ERR_pop_to_mark() Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-18EVP: Add evp_pkey_make_provided() and refactor around itRichard Levitte
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: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10850)
2020-01-15Change returned -2 to 0 in EVP_Digest{Sign,Verify}Init()Richard Levitte
The returned -2 was to mark when these operations are unsupported. However, that breaks away from the previous API and expectations, and there's not enough justification for that not being zero. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10815)
2020-01-14Fix EVP_Digest{Sign,Verify}Final() and EVP_Digest{Sign,Verify}() for ↵Richard Levitte
provider only keys For provider only keys where the initialization didn't catch, we may end up crashing because the legacy code path didn't check that it had support carefully enough. This only happens if the caller didn't check if initialization worked or not. For the one-shot case, it's very simply handling the case where the key has no legacy implementation an fall back to the standard init+update+final mechanism. While at it, EVP_DigestSignFinal() and EVP_DigestVerifyFinal() got a slight code cleanup. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10806)
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)
2020-01-08EVP: If a key can't be exported to provider, fallback to legacyRichard Levitte
Currently, the operations that do try to export a legacy key to providers will fail if the export failed. It makes more sense to simply use the legacy method instead, as a fallback for things not being implemented (yet) in a provider. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10771)
2019-11-05EVP: Make the SIGNATURE 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 SIGNATURE method explicitly, and rather always have it be fetched implicitly. This means fewer changes for applications that want to use new signature algorithms / implementations. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10303)
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-11Support calling EVP_DigestUpdate instead of EVP_Digest[Sign|Verify]UpdateMatt Caswell
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: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10116)
2019-10-03Don't call EVP_MD_CTX_reset during EVP_DigestFinalMatt Caswell
This resets the fields of the EVP_MD_CTX and means we can no longer make calls using the EVP_MD_CTX, such as to query parameters. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10013)
2019-10-03Add EVP_DigestSign/EVP_DigestVerify support for DSAMatt Caswell
Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10013)
2019-10-03Add the provider function signatures for DigestSign*Matt Caswell
Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10013)
2019-09-28Reorganize local header filesDr. Matthias St. Pierre
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: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
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)
2018-12-06Following the license change, modify the boilerplates in crypto/evp/Richard Levitte
[skip ci] Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7794)
2018-09-07Update document for SM2 stuffsPaul Yang
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7113)
2018-09-07Support setting SM2 IDPaul Yang
zero-length ID is allowed, but it's not allowed to skip the ID. Fixes: #6534 Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7113)
2018-09-07Support pmeth->digest_customPaul Yang
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7113)
2017-06-12Fix memleak in EVP_DigestSignFinal/VerifyFinal.Bernd Edlinger
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3658)
2017-05-30Add support for custom digestsign/digestverify methods.Dr. Stephen Henson
Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3503)
2017-05-11Add EVP_DigestSign and EVP_DigesVerifyDr. Stephen Henson
Add "single part" digest sign and verify functions. These sign and verify a message in one function. This simplifies some operations and it will later be used as the API for algorithms which do not support the update/final mechanism (e.g. PureEdDSA). Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3409)
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-23 11:49:24 +0000