Prepopulation of the stored namemap from the legacy method object
database happened on first EVP fetch. However, there are moments when
that prepopulation needs to happen even though no fetching has been
performed yet. We therefore move pre-population to happen when the
namemap is constructed.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10846)
Use of the low level RC5 functions has been informally discouraged for a long
time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10834)
Use of the low level RC4 functions has been informally discouraged for a long
time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10834)
Use of the low level RC2 functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10834)
Use of the low level SEED functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10833)
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)
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)
If we're using an explicitly fetched digest in an EVP_DigestUpdate
operation, then we should still go the legacy route if
EVP_MD_CTX_FLAG_NO_INIT has been set because we are being used in the
context of a legacy signature algorithm and EVP_DigestInit has not been
called.
This fixes a seg fault in EVP_DigestSignUpdate()
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10796)
Applications should instead use the higher level EVP APIs, e.g.
EVP_Encrypt*() and EVP_Decrypt*().
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10742)
Applications should instead use the higher level EVP APIs, e.g.
EVP_Encrypt*() and EVP_Decrypt*().
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10741)
Use of the low level Whirlpool functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_Digest,
EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10779)
Use of the low level RIPEMD160 functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_Digest,
EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10789)
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)
This will allow keymgmt implementation for key types that need it to
specify the names of the diverse operation algorithms it can be used
with. Currently, only one name per key type and operation is allowed.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10647)
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)
Applications should instead use the higher level EVP APIs, e.g.
EVP_Encrypt*() and EVP_Decrypt*().
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10740)
Use of the low level AES functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10580)
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: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/10758)
Also Add ability for providers to dynamically exclude cipher algorithms.
Cipher algorithms are only returned from providers if their capable() method is either NULL,
or the method returns 1.
This is mainly required for ciphers that only have hardware implementations.
If there is no hardware support, then the algorithm needs to be not available.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10146)
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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10531)
Macros have been added to generate the simple legacy methods.
Engines and EVP_MD_METH_get methods still require access to the old legacy methods,
so they needed to be added back in.
They may only be removed after engines are deprecated and removed.
Removed some unnecessary #includes and #ifndef guards (which are done in build.info instead).
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10602)
The case when EVP_PKEY_CTX_new() is called with a provided EVP_PKEY
(no legacy data) wasn't handled properly.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10618)
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: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10593)
So far, the API level method constructors that are called by
ossl_method_construct_this() were passed the algorithm name string and
the dispatch table and had no access to anything else.
This change gives them access to the full OSSL_ALGORITHM item, thereby
giving them access to the property definition.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
This was originally the private add_names_to_namemap() in
crypto/evp/evp_fetch.c, but made more generally useful.
To make for more consistent function naming, ossl_namemap_add() and
ossl_namemap_add_n() are renamed to ossl_namemap_add_name() and
ossl_namemap_add_name_n().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
We were missing a NULL check in a few very similar places following an
OPENSSL_zalloc() call.
Reported-by: Ziyang Li (@Liby99)
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10526)
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
(Merged from https://github.com/openssl/openssl/pull/10461)
Check for NULL and return error if so.
This can possibly be called from apps/ca.c with a NULL argument.
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/10474)
This adds ossl_namemap_empty(), to detect if a namemap is empty and
can thereby be pre-populated.
This also affects the way legacy NIDs are looked up in
evp_cipher_from_dispatch() and evp_md_from_dispatch(). Instead of
trying to find the NID directly, look up the legacy method structure
and grab the NID from there. The reason is that NIDs can be aliases
for other NIDs, which looks like a clash even if wasn't really one.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8984)
In addition to 67c81ec3 which introduced this behavior in CCM mode
docs but only implemented it for AES-CCM.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10331)
EVP_CIPHER_CTX_set_keylen() was succeeding even though a bad key length
is passed to it. This is because the set_ctx_params() were all accepting
this parameter and blindly changing the keylen even though the cipher did
not accept a variable key length. Even removing this didn't entirely
resolve the issue because set_ctx_params() functions succeed even if
passed a parameter they do not recognise.
This should fix various issues found by OSSfuzz/Cryptofuzz.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10449)
The property query cache was not reference count aware and this could cause
problems if the property store removes an algorithm while it is being returned
from an asynchronous query. This change makes the cache reference count aware
and avoids disappearing algorithms.
A side effect of this change is that the reference counts are now owned by the
cache and store.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10408)
We modify the build.info file to exclude the legacy_blake2.c file in
the event that blake2 support has been disabled.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10425)
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)
Now that KEYMGMT method pointers have moved away from the diverse
methods that are used with EVP_PKEY_CTX, we no longer need to pass
special argument to evp_generic_fetch() and evp_generic_do_all().
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10309)
