ECX_KEY was not meant for public consumption, it was only to be
accessed indirectly via EVP routines. However, we still need internal
access for our decoders.
This partially reverts 7c664b1f1bFixes#12880
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12956)
This is required before the RAND/DRBG framework can be made user mutable.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12904)
This adds the convenience function EVP_PKEY_typenames_do_all(), which
does the same as EVP_KEYMGMT_names_do_all(), but without having to
expose all the internal ways to find out if the internal EVP_PKEY key
is legacy or provider-native.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12873)
SP800-56Br2 requires support for the RSA primitives for RSASVE generate and recover.
As these are simple KEM operations another operation type has been added that can support future extensions.
Added public functions EVP_PKEY_encapsulate_init(), EVP_PKEY_encapsulate(), EVP_PKEY_decapsulate_init() and EVP_PKEY_decapsulate()
Added EVP_KEM_* functions.
Added OSSL_FUNC_kem_* dispatch functions
Added EVP_PKEY_CTX_set_kem_op() so that different types of KEM can be added in the future. This value must currently be set to
"RSASVE" after EVP_PKEY_encapsulate_init() & EVP_PKEY_decapsulate_init() as there is no default value.
This allows the existing RSA key types, keymanagers, and encoders to be used with the encapsulation operations.
The design of the public API's resulted from contributions from @romen & @levitte.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12750)
In OpenSSL 1.1.1 doing an HMAC operation with (say) SHA1 would produce
output like this:
HMAC-SHA1(README.md)= 553154e4c0109ddc320bb495735906ad7135c2f1
Prior to this change master would instead display this like so:
SHA1(README.md)= 553154e4c0109ddc320bb495735906ad7135c2f1
The problem is that dgst was using EVP_PKEY_asn1_get0_info() to get
the algorithm name from the EVP_PKEY. This doesn't work with provider
based keys. Instead we introduce a new EVP_PKEY_get0_first_alg_name()
function, and an equivalent EVP_KEYMGMT_get0_first_name() function.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12850)
Prior to OpenSSL 3.0 calling EVP_DigestInit_ex() on an mdctx previously
initialised with EVP_DigestSignInit() would retain information about the
key, and re-initialise for another sign operation. To emulate that we
redirect calls to EVP_DigestInit() to EVP_DigestSignInit_ex() if
appropriate.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12850)
SP800-56br2 requires seperate KAT's (fips self tests) to be tested for both encryption and decryption
using the RSA primitive (i.e. no padding). This is specified in FIPS140-2 IG D.9
A copy of the methods EVP_PKEY_encrypt_init(), EVP_PKEY_encrypt(), EVP_PKEY_decrypt_init(), EVP_PKEY_decrypt()
are now in the fips module.
Removed the #ifdef FIPS_MODULE in evp_pkey_ctx_free_old_ops().
Added corruption test
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12835)
Instead of sometimes, and sometimes not reporting an error in the
caller of EVP_XXX_fetch(), where the error may or may not be very
accurate, it's now centralised to the inner EVP fetch functionality.
It's made in such a way that it can determine if an error occured
because the algorithm in question is not there, or if something else
went wrong, and will report EVP_R_UNSUPPORTED_ALGORITHM for the
former, and EVP_R_FETCH_FAILED for the latter.
This helps our own test/evp_test.c when it tries to figure out why an
EVP_PKEY it tried to load failed to do so.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12857)
This is purely to allow exporting without having to repeatedly specify
the keymgmt and keydata from the EVP_PKEY.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12853)
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)
PEM_write_bio_PrivateKey_traditional() didn't handle provider-native
keys very well. Originally, it would simply use the corresponding
encoder, which is likely to output modern PEM (not "traditional").
PEM_write_bio_PrivateKey_traditional() is now changed to try and get a
legacy copy of the input EVP_PKEY, and use that copy for traditional
output, if it has such support.
Internally, evp_pkey_copy_downgraded() is added, to be used when
evp_pkey_downgrade() is too intrusive for what it's needed for.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12738)
Add the AuthEnvelopedData as defined in RFC 5083 with AES-GCM
parameter as defined in RFC 5084.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/8024)
Those functions were located in the EC files, but is really broader
than that, even thought currently only used for SM2. They should
therefore be in a more central location, which was also indicated by
diverse TODOs.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12789)
Setting a hash function was reserved for signature operations.
However, it turns out that SM2 uses a hash function for encryption and
decryption as well.
Therefore, EVP_PKEY_CTX_md() must be called with an expanded operation
type combination that includes EVP_PKEY_OP_TYPE_CRYPT when used in a
generic way.
For SM2, test/recipes/30-test_evp_data/evppkey_sm2.txt is expanded to
test decryption both with an implicit and an explicit digest.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12789)
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)
There are places that add an ERR_R_MALLOC_FAILURE record when any of
EVP_PKEY_CTX_new*() return NULL, which is 1) inaccurate, and 2)
shadows the more accurate error record generated when trying to create
the EVP_PKEY_CTX.
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/12785)
As long as there are internal legacy keys for EVP_PKEY, we need to preserve
the EVP_PKEY numeric identity when generating a key, and when creating the
EVP_PKEY_CTX.
For added consistency, the EVP_PKEY_CTX contructor tries a little
harder to find a EVP_PKEY_METHOD. Otherwise, we may run into
situations where the EVP_PKEY_CTX ends up having no associated methods
at all.
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/12785)
On failure by EVP_PKEY_CTX_new_from_name(), this function reported
ERR_R_MALLOC_FAILURE. However, that's not necessarily true, as it can
fail because the algorithm isn't present.
Either way, EVP_PKEY_CTX_new_from_name() records more accurate errors
on its own, and one of them - EVP_R_FETCH_FAILED - is significant for
test/evp_test.c.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
EVP_PKEY2PKCS8() relies on the presence of an EVP_PKEY_ASN1_METHOD,
which requires "downgrading" the EVP_PKEY to have a legacy internal
key.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
From this point on, this engine must be specifically specified.
To replace the internal EMBEDDED hack with something unique for the
new module, functions to create application specific OSSL_STORE_INFO
types were added.
Furthermore, the following function had to be exported:
ossl_do_blob_header()
ossl_do_PVK_header()
asn1_d2i_read_bio()
Finally, evp_pkcs82pkey_int() has become public under a new name,
EVP_PKCS82PKEY_with_libctx()
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
We leave it up to the EVP_MAC implemenations what to do with an update
where the data length is 0. In the TLS HMAC implemenation this is still
signficant.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12732)
We reuse concepts such as PROV_CIPHER, and make use of some common code
in provider_util.c
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
Now that the all the legacy PKEY MAC bridge code has been moved to the
providers we no longer need the old bridge and it can be removed.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
The previous commits added support for HMAC, SIPHASH and Poly1305 into
the provider MAC bridge. We now extend that for CMAC too.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
The previous commits added support for HMAC and SIPHASH into the provider
MAC bridge. We now extend that for Poly1305 too.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
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)
The previous commits added support for HMAC into the provider MAC bridge.
We now extend that for SIPHASH too.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
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)
Previously it was a macro. We now make it into a function that is params
aware.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
