The EVP layer should not rely on the underlying low level code to
handle catching incorrect reuse of contexts.
Add a flag to mark a context as finalised as needed and then catch and
immediately error on Update/Final operations if called improperly.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/20375)
If the ctx was *really* needed we'll probably fail later with an error
anyway, so no point in failing immediately.
Document that this behavior is dependent on the provider used to
implement the signature/verification.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/20375)
Fixes#16947
Also refactor out algctx freeing into a separate function.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18105)
Partial fix for #17064. Avoid excessive writes to the cache line
containing the refcount for an EVP_MD object to avoid extreme
cache contention when using a single EVP_MD at high frequency on
multiple threads. This changes performance in 3.0 from being double
that of 1.1 to only slightly higher than that of 1.1.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17857)
Functions like EVP_PKEY_sign_init() do an implicit fetch of the
operation implementation (EVP_SIGNATURE in this case), then get the
KEYMGMT from the same provider, and tries to export the key there if
necessary.
If an export of the key isn't possible (because the provider that
holds the key is an HSM and therefore can't export), we would simply
fail without looking any further.
This change modifies the behaviour a bit by trying a second fetch of
the operation implementation, but specifically from the provider of
the EVP_PKEY that's being used. This is done with the same properties
that were used with the initial operation implementation fetch, and
should therefore be safe, allowing only what those properties allow.
Fixes#16614
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16725)
In all initializing functions for functionality that use an EVP_PKEY, the
coded logic was to find an KEYMGMT implementation first, and then try to
find the operation method (for example, SIGNATURE implementation) in the
same provider.
This implies that in providers where there is a KEYMGMT implementation,
there must also be a SIGNATURE implementation, along with a KEYEXCH,
ASYM_CIPHER, etc implementation.
The intended design was, however, the opposite implication, i.e. that
where there is a SIGNATURE implementation, there must also be KEYMGMT.
This change reverses the logic of the code to be closer to the intended
design.
There is a consequence; we now use the query_operation_name function from
the KEYMGMT of the EVP_PKEY given by the EVP_PKEY_CTX (ultimately given by
the application). Previously, we used the query_operation_name function
from the KEYMGMT found alongside the SIGNATURE implementation.
Another minor consequence is that the |keymgmt| field in EVP_PKEY_CTX
is now always a reference to the KEYMGMT of the |pkey| field if that
one is given (|pkey| isn't NULL) and is provided (|pkey->keymgmt|
isn't NULL).
Fixes#16614
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16725)
If an application bug means that a buffer smaller than is necessary is
passed to various functions then OpenSSL does not spot that the buffer
is too small and fills it anyway. This PR prevents that.
Since it requires an application bug to hit this problem, no CVE is
allocated.
Thanks to David Benjamin for reporting this issue.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16789)
The legacy implementation duplicates the pctx before creating/verifying
the signature unless EVP_MD_CTX_FLAG_FINALISE is set. We have to do the
same with provided implementations.
Fixes#16321
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16422)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16138)
If no digest is specified, the code looks for a default digest per PKEY via the
evp_keymgmt_util_get_deflt_digest_name() call. If this call returns NULL,
indicating no digest found, the code continues regardless. If the verify/sign
init later fails, it returns an error without raising one. This change raises
an error in this case.
Fixes#15372
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16015)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15974)
For functions that exist in 1.1.1 provide a simple aliases via #define.
Fixes#15236
Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_,
EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_,
EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_,
EVP_MD_, and EVP_CIPHER_ prefixes are renamed.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15405)
pointers to provider size algorithm contexts.
Fixes#14284
The gettable_ctx_params methods were confusingly passing a 'provctx' and
a provider context which are completely different objects.
Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'.
For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm
implementation creates an internal context using a new_ctx() method.
Hence the new name 'algctx'.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15275)
Add a "where did this EVP_{CIPHER,MD} come from" flag: global, via fetch,
or via EVP_{CIPHER,MD}_meth_new. Update EVP_{CIPHER,MD}_free to handle all
three origins. The flag is deliberately right before some function pointers,
so that compile-time failures (int/pointer) will occur, as opposed to
taking a bit in the existing "flags" field. The "global variable" flag
is non-zero, so the default case of using OPENSSL_zalloc (for provider
ciphers), will do the right thing. Ref-counting is a no-op for
Make up_ref no-op for global MD and CIPHER objects
Deprecate EVP_MD_CTX_md(). Added EVP_MD_CTX_get0_md() (same semantics as
the deprecated function) and EVP_MD_CTX_get1_md(). Likewise, deprecate
EVP_CIPHER_CTX_cipher() in favor of EVP_CIPHER_CTX_get0_cipher(), and add
EVP_CIPHER_CTX_get1_CIPHER().
Refactor EVP_MD_free() and EVP_MD_meth_free() to call new common
evp_md_free_int() function.
Refactor EVP_CIPHER_free() and EVP_CIPHER_meth_free() to call new common
evp_cipher_free_int() function.
Also change some flags tests to explicit test == or != zero. E.g.,
if (flags & x) --> if ((flags & x) != 0)
if (!(flags & x)) --> if ((flags & x) == 0)
Only done for those lines where "get0_cipher" calls were made.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14193)
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)
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)
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)
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)
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)
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)
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)
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)
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)
-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)
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)
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)
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)
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)
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)
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)
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)
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#11179Fixes#9915
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11193)
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)
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)
