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)
Instead of passing the length in from the caller, compute the length
to pass to setsockopt() inside of ktls_start(). This isolates the
OS-specific behavior to ktls.h and removes it from the socket BIO
implementations.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/12782)
This is mostly a cosmetic cleanup I missed when adding the
ktls_crypto_info_t type. However, while fixing this I noticed that
the changes to extract the size from crypto_info from the wrapper
structure for Linux KTLS had not been propagated from bss_sock.c to
bss_conn.c, so I've fixed that to use the correct length.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/12782)
* Add -own_trusted option to CMP app
* Add OSSL_CMP_CTX_build_cert_chain()
* Add optional trust store arg to ossl_cmp_build_cert_chain()
* Extend the tests in cmp_protect_test.c and the documentation accordingly
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12791)
In EC_GROUP_new_from_params(), ERR_R_EC_LIB was reported if
group_new_from_name() returned NULL. However, this shadows a possible
EC_R_INVALID_CURVE, making that harder to detect, which happens to be
important to do in test/evp_test.c.
This also extends key_unsupported() in test/evp_test.c to check for
this error alongside the check for EC_R_UNKNOWN_GROUP.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
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)
The old 'file:' loader was recently changed to stop the flood of
repeated nested ASN.1 errors when trying to decode a DER blob in
diverse ways.
That is now reproduced in ossl_store_handle_load_result()
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
Passphrase caching didn't allocate memory when it got to cache an
empty string, leading to a crash.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
Some sub-systems and openssl sub-commands do not yet deal cleanly with
purely provider-native EVP_PKEYs. We compensate that by "downgrading"
keys in select places, or ensure that the 'file:' scheme ENGINE loader
is activated.
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)
This replaces the older 'file:' loader that is now an engine.
It's still possible to use the older 'file:' loader by explicitly
using the engine, and tests will remain for it as long as ENGINEs are
still supported (even through deprecated).
To support this storemgmt implementation, a few internal OSSL_DECODER
modifications are needed:
- An internal function that implements most of
OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already
existing OSSL_DECODER_CTX instead of allocating a new one.
- Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM.
It isn't attached to any provider, and is only used internally, to
simply catch any DER encoded object to be passed back to the
object callback with no further checking. This implementation
becomes the last resort decoder, when all "normal"
decodation attempts (i.e. those that are supposed to result
in an OpenSSL object of some sort) have failed.
Because file_store_attach() uses BIO_tell(), we must also support
BIO_ctrl() as a libcrypto upcall.
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)
The TLS HMAC implementation should take care to calculate the MAC in
constant time in the case of MAC-Then-Encrypt where we have a variable
amount of padding.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12732)
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12755)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/12760)
Fix OPENSSL_realloc failure case; `provider->operation_bits` memory
is lost when `OPENSSL_realloc()` returns NULL.
`operation_bits_sz` is never set to the length of the allocated array.
This means that operation_bits is always reallocated in
`ossl_provider_set_operation_bit()`, possibly shrinking the array.
In addition, it means that the `memset()` always zeros out the
whole reallocated array, not just the new part. Also, because
`operation_bits_sz` is always zero, the value of `*result` in
`ossl_provider_test_operation_bit()` will always be zero.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/12760)
* In the cmp app so far the -verbosity option had been missing.
* Extend log output helpful for debugging CMP applications
in setup_ssl_ctx() of the cmp app, ossl_cmp_msg_add_extraCerts(),
OSSL_CMP_validate_msg(), and OSSL_CMP_MSG_http_perform().
* Correct suppression of log output with insufficient severity.
* Add logging/severity level OSSL_CMP_LOG_TRACE = OSSL_CMP_LOG_MAX.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12739)
If a digest is not available we just get an "internal error" error
message - which isn't very helpful for diagnosing problems. Instead we
explicitly state that we couldn't find a suitable digest.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12733)
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)
PEM_write_bio_PrivateKey_traditional() uses i2d_PrivateKey() to do the
actual encoding to DER. However, i2d_PrivateKey() is a generic
function that will do what it can to produce output according to what
the associated EVP_PKEY_ASN1_METHOD offers. If that method offers a
function 'old_priv_encode', which is expected to produce the
"traditional" encoded form, then i2d_PrivateKey() uses that. If not,
i2d_PrivateKey() will go on and used more modern methods, which are
all expected to produce PKCS#8.
To ensure that PEM_write_bio_PrivateKey_traditional() never produces
more modern encoded forms, an extra check that 'old_priv_encode' is
non-NULL is added. If it is NULL, an error is returned.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12728)
Add an option to configuration files "config_diagnostics" that when set to a
non-zero value, overrides the error ignoring flags. The outcome is that
diagnostic option is produced when e.g. sections are missing.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12663)
For example, FreeBSD prepends "FreeBSD" to version string, e.g.,
FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc2-0-g414f32a9e86)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
This prevented us from properly detecting AVX support, etc.
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/12725)
This adds a flag, OCSP_PARTIAL_CHAIN, to the OCSP_basic_verify()
function. This is equivlent to X509_V_FLAG_PARTIAL_CHAIN, in that
if any certificate in the OCSP response is in the trust store, then
trust it.
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12666)
This adds the needed code to make the OSSL_STORE API functions handle
provided STORE implementations.
This also modifies OSSL_STORE_attach() for have the URI, the
library context and the properties in the same order as
OSSL_STORE_open_with_libctx().
The most notable change, though, is how this creates a division of
labor between libcrypto and any storemgmt implementation that wants to
pass X.509, X.509 CRL, etc structures back to libcrypto. Since those
structures aren't directly supported in the libcrypto <-> provider
interface (asymmetric keys being the only exception so far), we resort
to a libcrypto object callback that can handle passed data in DER form
and does its part of figuring out what the DER content actually is.
This also adds the internal x509_crl_set0_libctx(), which works just
like x509_set0_libctx(), but for X509_CRL.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
This makes it possible to use OSSL_DECODER in functions that are passed
a OSSL_PASSPHRASE_CALLBACK already.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
When some function receives an OSSL_PARAM array to pilfer for data,
and there is a string of some sort, and all the code needs is to get
the pointer to the data, rather than a copy, there is currently no
other way than to use |param->data| directly. This is of course a
valid method, but lacks any safety check (is |param->data_type|
correct, for example?).
OSSL_PARAM_get_utf8_string_ptr() and OSSL_PARAM_get_octet_string_ptr()
helps the programmer with such things, by setting the argument pointer
to |param->data|.
Additionally, the handle the data types OSSL_PARAM_UTF8_PTR and
OSSL_PARAM_OCTET_PTR as well.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
This includes fixing a bug that could only be discovered when no
loaders were registered.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
The pass phrase prompter that's part of OSSL_ENCODER and OSSL_DECODER
is really a passphrase callback bridge between the diverse forms of
prompters that exist within OpenSSL: pem_password_cb, ui_method and
OSSL_PASSPHRASE_CALLBACK.
This can be generalised, to be re-used by other parts of OpenSSL, and
to thereby allow the users to specify whatever form of pass phrase
callback they need, while being able to pass that on to other APIs
that are called internally, in the form that those APIs demand.
Additionally, we throw in the possibility to cache pass phrases during
a "session" (we leave it to each API to define what a "session" is).
This is useful for any API that implements discovery and therefore may
need to get the same password more than once, such as OSSL_DECODER and
OSSL_STORE.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
This is placed as CORE because the core of libcrypto is the authority
for what is possible to do and what's required to make these abstract
objects work.
In essence, an abstract object is an OSSL_PARAM array with well
defined parameter keys and values:
- an object type, which is a number indicating what kind of
libcrypto structure the object in question can be used with. The
currently possible numbers are defined in <openssl/core_object.h>.
- an object data type, which is a string that indicates more closely
what the contents of the object are.
- the object data, an octet string. The exact encoding used depends
on the context in which it's used. For example, the decoder
sub-system accepts any encoding, as long as there is a decoder
implementation that takes that as input. If central code is to
handle the data directly, DER encoding is assumed. (*)
- an object reference, also an octet string. This octet string is
not the object contents, just a mere reference to a provider-native
object. (**)
- an object description, which is a human readable text string that
can be displayed if some software desires to do so.
The intent is that certain provider-native operations (called X
here) are able to return any sort of object that belong with other
operations, or an object that has no provider support otherwise.
(*) A future extension might be to be able to specify encoding.
(**) The possible mechanisms for dealing with object references are:
- An object loading function in the target operation. The exact
target operation is determined by the object type (for example,
OSSL_OBJECT_PKEY implies that the target operation is a KEYMGMT)
and the implementation to be fetched by its object data type (for
an OSSL_OBJECT_PKEY, that's the KEYMGMT keytype to be fetched).
This loading function is only useful for this if the implementations
that are involved (X and KEYMGMT, for example) are from the same
provider.
- An object exporter function in the operation X implementation.
That exporter function can be used to export the object data in
OSSL_PARAM form that can be imported by a target operation's
import function. This can be used when it's not possible to fetch
the target operation implementation from the same provider.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
Fixes#12633
For CMS the Gost engine still requires calls to EVP_get_digestbyname() and EVP_get_cipherbyname() when
EVP_MD_fetch() and EVP_CIPHER_fetch() return NULL.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12689)
This was added for backward compatability.
Added EC_GROUP_new_from_params() that supports explicit curve parameters.
This fixes the 15-test_genec.t TODO.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12604)
Also remove not really to-the-point error message if call fails in apps/cmp.c
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11808)
PEM_read_bio_PUBKEY_ex() and PEM_read_bio_Parameters_ex() are added to
complete PEM_read_bio_PrivateKey_ex(). They are all refactored to be
wrappers around the same internal function.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12673)
While public keys and private keys use the same type (EVP_PKEY), just
with different contents, callers still need to distinguish between the
two to be able to know what functions to call with them (for example,
to be able to choose between EVP_PKEY_print_private() and
EVP_PKEY_print_public()).
The OSSL_STORE backend knows what it loaded, so it has the capacity to
inform.
Note that the same as usual still applies, that a private key EVP_PKEY
contains the public parts, but not necessarily the other way around.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12673)
If those private key serializer were given a key structure with just
the public key material, they crashed, because they tried to
de-reference NULL. This adds better checking.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12679)
Just like d2i_PrivateKey() / d2i_PrivateKey_ex(), there's a need to
associate an EVP_PKEY extracted from a PUBKEY to a library context and
a property query string. Without it, a provider-native EVP_PKEY can
only fetch necessary internal algorithms from the default library
context, even though an application specific context should be used.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12671)
The RSA key could be a public key, and yet, rsa_todata() always tries
to add the private parts as well. The resulting parameters will look
a bit odd, such as a zero |d|, resulting in an invalid key.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12676)
There are some EC keys that can't be exported to provider keymgmt,
because the keymgmt implementation doesn't support certain forms of EC
keys. This could lead to a crash caused by dereferencing a NULL
pointer, so we need to cover that case by returning an error instead.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12610)
Fixes#12640
The X942-KDF is now indepedent of the CMS code (since it no longer uses CMS_SharedInfo_encode).
Any code related to EVP_PKEY_DH_KDF_X9_42 needs to not be wrapped by !defined(OPENSSL_NO_CMS).
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12642)
The calls are unlikely to fail but better checking their return than not.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12648)
Fixes#12589
The 'type' parameter needed to be propagated to the ffc params during keygen,
so that the simple validation of params done during keygen can handle legacy keys for the default provider.
The fips provider ignores this change and only allows fips186-4 approved sizes.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12623)
A config file can change the global default properties. Therefore we
must ensure that the config file is loaded before reading or amending
them.
Fixes#12565
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12567)
If an attempt is made to load a provider and it fails, the fall-back mechanism
should be disabled to prevent the user getting some weird happening. E.g. a
failure to load the FIPS provider should not allow the default to load as a
fall-back.
The OSSL_PROVIDER_try_load() call has been added, to allow a provider to be
loaded without disabling the fall-back mechanism if it fails.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12625)
This KDF is defined in RFC7292 in appendix B. It is widely used in PKCS#12
and should be provided.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12624)
RSA keys in the 'base' provider are different from a fips provider RSA key (since they have different object structures).
To use a fips provider key in the base serializer the key needs to be exported.
The fix was suggested by @levitte.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12162)
Use EVP_CIPHER_CTX_get_iv() to implement EVP_CIPHER_set_asn1_iv(),
rather than the deprecated EVP_CIPHER_CTX_original_iv().
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in evp.h.
These macros are internal-only, used to implement legacy libcrypto
EVP ciphers, with no real provider involvement. Accordingly, just use the
EVP_CIPHER_CTX storage directly and don't try to reach into a provider-side
context.
This does necessitate including evp_local.h in several more files.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_rc2.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_xcbc_d.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_sm4.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_des3.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_des.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_camellia.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_aria.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_aes_cbc_hmac_sha256.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_aes_cbc_hmac_sha1.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_aes.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
It is superseded by EVP_CIPHER_CTX_get_iv(), is only present on master,
and had only a couple of in-tree callers that are easy to convert.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
The EVP_CIPHER_CTX_iv() family of functions are incompatible with
the libcrypto/provider separation, since the implied API contract
(they are undocumented) involves a pointer into the active cipher
context structure. However, the active IV data in a provider-side
context need not even be in the same address space as libcrypto,
so a replacement API is needed.
The existing functions for accessing the (even the "original") IV had
remained undocumented for quite some time, presumably due to unease
about exposing the internals of the cipher state in such a manner.
Provide more maintainable new APIs for accessing the initial ("oiv") and
current-state ("iv") IV data, that copy the value into a caller-provided
array, eliminating the need to provide a pointer into the internal
cipher context, which accordingly no longer provides the ability to
write to the internal cipher state.
Unfortunately, in order to maintain API compatibility with OpenSSL
1.1.1, the old functionality is still available, but is marked as
deprecated for future removal. This would entail removing the "octet
pointer" parameter access, leaving only the "octet string" parameter
type.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Some modes (e.g., CBC and OFB) update the effective IV with each
block-cipher invocation, making the "IV" stored in the (historically)
EVP_CIPHER_CTX or (current) PROV_CIPHER_CTX distinct from the initial
IV passed in at cipher initialization time. The latter is stored in
the "oiv" (original IV) field, and has historically been accessible
via the EVP_CIPHER_CTX_original_iv() API. The "effective IV" has
also historically been accessible, via both EVP_CIPHER_CTX_iv()
and EVP_CIPHER_CTX_iv_noconst(), the latter of which allows for
*write* access to the internal cipher state. This is particularly
problematic given that provider-internal cipher state need not, in
general, even be accessible from the same address space as libcrypto,
so these APIs are not sustainable in the long term. However, it still
remains necessary to provide access to the contents of the "IV state"
(e.g., when serializing cipher state for in-kernel TLS); a subsequent
reinitialization of a cipher context using the "IV state" as the
input IV will be able to resume processing of data in a compatible
manner.
This problem was introduced in commit
089cb623be, which effectively caused
all IV queries to return the "original IV", removing access to the
current IV state of the cipher.
These functions for accessing the (even the "original") IV had remained
undocumented for quite some time, presumably due to unease about
exposing the internals of the cipher state in such a manner.
Note that this also as a side effect "fixes" some "bugs" where things
had been referring to the 'iv' field that should have been using the
'oiv' field. It also fixes the EVP_CTRL_GET_IV cipher control,
which was clearly intended to expose the non-original IV, for
use exporting the cipher state into the kernel for kTLS.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Similiar to ecdh this supports the legacy kdf inside the provider dh key exchange.
The supporting EVP_PKEY_CTX macros have been changed into mehtods and moved into dh_ctrl.c
New kdfs such as SSKDF should be done as a seperate pass after doing the derive.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12575)
The KDF bridge is now done provider side so the old EVP_PKEY_METHODS for
this are no longer required.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12573)
Some KDF implementations were available before the current EVP_KDF API.
They were used via EVP_PKEY_derive. There exists a bridge between the old
API and the EVP_KDF API however this bridge itself uses a legacy
EVP_PKEY_METHOD. This commit implements a provider side bridge without
having to use any legacy code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12573)
The default and legacy providers currently return 1 for status and self test checks.
Added test to show the 3 different stages the self test can be run (for installation, loading and on demand).
For the fips provider:
- If the on demand self test fails, then any subsequent fetches should also fail. To implement this the
cached algorithms are flushed on failure.
- getting the self test callback in the fips provider is a bit complicated since the callback hangs off the core
libctx (as it is set by the application) not the actual fips library context. Also the callback can be set at
any time not just during the OSSL_provider_init() so it is calculated each time before doing any self test.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11752)
-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)
-Public PKCS7 methods that create a PKCS7 object now have variants that also add a libctx and propq.
This includes PKCS7_new_with_libctx(), PKCS7_sign_with_libctx() and PKCS7_encrypt_with_libctx()
-Added SMIME_read_PKCS7_ex() so that a created PKCS7 object can be passed to the read.
-d2i_PKCS7_bio() has been modified so that after it loads the PKCS7 object it then resolves any subobjects that require
the libctx/propq (such as objects containing X509 certificates).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11884)
Added SMIME_write_ASN1_with_libctx() since it fetches rand internally.
Added SMIME_read_CMS_ex() so that a created object (CMS_ContentInfo) can be passed to the read.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11884)
This should only be called during (or right after) using d2iXXX on a object that contains embedded certificate(s)
that require a non default library context. X509_new_with_libctx() should be used if possible.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11884)
-Public CMS methods that create a CMS_ContentInfo object now have variants that also add a libctx and propq.
This includes CMS_ContentInfo_new_with_libctx(), CMS_sign_with_libctx(), CMS_data_create_with_libctx(),
CMS_digest_create_with_libctx(), CMS_EncryptedData_encrypt_with_libctx(), CMS_EnvelopedData_create_with_libctx().
-Added CMS_ReceiptRequest_create0_with_libctx().
-Added SMIME_read_CMS_ex() so that a new CMS_ContentInfo object (created using CMS_ContentInfo_new_with_libctx()) can
be passed to the read.
-d2i_CMS_bio() has been modified so that after it loads the CMS_ContentInfo() it then resolves any subobjects that require
the libctx/propq (such as objects containing X509 certificates).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11884)
Changed many tests so they also test fips (and removed 'availablein = default' from some tests).
Seperated the monolithic evppkey.txt file into smaller maintainable groups.
Changed the availablein option so it must be first - this then skips the entire test before any fetching happens.
Changed the code so that all the OPENSSL_NO_XXXX tests are done in code via methods such as is_cipher_disabled(alg),
before the fetch happens.
Added missing libctx's found by adding a libctx to test_evp.
Broke up large data files for cipher, kdf's and mac's into smaller pieces so they no longer need 'AvailableIn = default'
Added missing algorithm aliases for cipher/digests to the providers.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12236)
The RAND_DRBG API did not fit well into the new provider concept as
implemented by EVP_RAND and EVP_RAND_CTX. The main reason is that the
RAND_DRBG API is a mixture of 'front end' and 'back end' API calls
and some of its API calls are rather low-level. This holds in particular
for the callback mechanism (RAND_DRBG_set_callbacks()) and the RAND_DRBG
type changing mechanism (RAND_DRBG_set()).
Adding a compatibility layer to continue supporting the RAND_DRBG API as
a legacy API for a regular deprecation period turned out to come at the
price of complicating the new provider API unnecessarily. Since the
RAND_DRBG API exists only since version 1.1.1, it was decided by the OMC
to drop it entirely.
Other related changes:
Use RNG instead of DRBG in EVP_RAND documentation. The documentation was
using DRBG in places where it should have been RNG or CSRNG.
Move the RAND_DRBG(7) documentation to EVP_RAND(7).
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12509)
Trust the returned value from EVP_PKEY_get_default_digest_name()! It
mimics exactly the values that EVP_PKEY_get_default_digest_nid() is
supposed to return, and that value should simply be passed unchanged.
Callers depend on it.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12586)
A key type may be deserialized from one of several sources, which
means that more than one deserializer with the same name should be
possible to add to the stack of deserializers to try, in the
OSSL_DESERIALIZER_CTX collection.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12574)
Fly-by fix is to move crypto/include/internal/pem_int.h to
include/internal/pem.h.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12574)
We have a key in test/recipes/30-test_evp_data/evppkey.txt with bad
PSS parameters (RSA-PSS-BAD), which is supposed to trigger signature
computation faults. However, if this key needs to be exported to the
RSA provider implementation, the result would be an earlier error,
giving the computation that's supposed to be checked n chance to even
be reached.
Either way, the legacy to provider export is no place to validate the
values of the key.
We also ensure that the provider implementation can handle and detect
signed (negative) saltlen values.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12583)
The various MACs were all over the place with respects to what they did with
the output length in the final call. Now they all unconditionally set the
output length and the EVP layer handles the possibility of a NULL pointer.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12582)
When the keymgmt provider and the deserializer provider differ,
deserialization uses the deserializer export function instead of the
keymgmt load, with a selection of what parts should be exported. That
selection was set to OSSL_KEYMGMT_SELECT_ALL_PARAMETERS when it should
have been OSSL_KEYMGMT_SELECT_ALL.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12571)
Added der_writer functions for writing octet string primitives.
Generate OID's for key wrapping algorithms used by X942 KDF.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12554)
Commit 6725682d introduced a call to ENGINE_get_digest_engine() into
the function asn1_item_digest_with_libctx() to determine whether there
is an ENGINE registered to handle the specified digest. However that
function increases the ref count on the returned ENGINE object, so it
must be freed.
Fixes#12558
[extended tests]
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12560)
Depending on the BIO used, using BIO_reset() may lead to "interesting"
results. For example, a BIO_f_buffer() on top of another BIO that
handles BIO_reset() as a BIO_seek(bio, 0), the deserialization process
may find itself with a file that's rewound more than expected.
Therefore, OSSL_DESERIALIZER_from_{bio,fp}'s behaviour is changed to
rely purely on BIO_tell() / BIO_seek(), and since BIO_s_mem() is used
internally, it's changed to handle BIO_tell() and BIO_seek() better.
This does currently mean that OSSL_DESERIALIZER can't be easily used
with streams that don't support BIO_tell() / BIO_seek().
Fixes#12541
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12544)
It's not the best idea to set a whole bunch of parameters in one call,
that leads to functions that are hard to update. Better to re-model
this into several function made to set one parameter each.
This also renames "finalizer" to "constructor", which was suggested
earlier but got lost at the time.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12544)
To be able to implement this, there was a need for the standard
EVP_PKEY_set1_, EVP_PKEY_get0_ and EVP_PKEY_get1_ functions for
ED25519, ED448, X25519 and X448, as well as the corresponding
EVP_PKEY_assign_ macros. There was also a need to extend the list of
hard coded names that EVP_PKEY_is_a() recognise.
Along with this, OSSL_FUNC_keymgmt_load() are implemented for all
those key types.
The deserializers for these key types are all implemented generically,
in providers/implementations/serializers/deserializer_der2key.c.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12544)
The OSSL_DESERIALIZER API makes the incorrect assumption that the
caller must cipher and other pass phrase related parameters to the
individual desserializer implementations, when the reality is that
they only need a passphrase callback, and will be able to figure out
the rest themselves from the input they get.
We simplify it further by never passing any explicit passphrase to the
provider implementation, and simply have them call the passphrase
callback unconditionally when they need, leaving it to libcrypto code
to juggle explicit passphrases, cached passphrases and actual
passphrase callback calls.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12544)
This is needed so RSA keys created from different code paths have a
chance to compare as equal.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12544)
For now, that's what we see being used. It's possible that we will
have to figure out a way to specific if these should be implicit or
explicit on a case by case basis.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12544)
Move the libcrypto serialisation functionality into a place where it can
be provided at some point. The serialisation still remains native in the
default provider.
Add additional code to the list command to display what kind of serialisation
each entry is capable of.
Having the FIPS provider auto load the base provider is a future
(but necessary) enhancement.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12104)
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)
The locking was too fine grained when adding entries to a namemap.
Refactored the working code into unlocked functions and call these with
appropriate locking.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12545)
This implements these functions:
OSSL_DESERIALIZER_CTX_set_cipher()
OSSL_DESERIALIZER_CTX_set_passphrase()
OSSL_DESERIALIZER_CTX_set_passphrase_ui()
OSSL_DESERIALIZER_CTX_set_passphrase_cb()
To be able to deal with multiple deserializers trying to work on the
same byte array and wanting to decrypt it while doing so, the
deserializer caches the passphrase. This cache is cleared at the end
of OSSL_DESERIALIZER_from_bio().
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
Serialization will only encrypt, so there's no point telling
OSSL_SERIALIZER_CTX_set_passphrase_cb() that's going to happen.
We fix the declaration of OSSL_DESERIALIZER_CTX_set_passphrase_cb()
the same way.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
EVP_PKEY is the fundamental type for provider side code, so we
implement specific support for it, in form of a special context
constructor.
This constructor looks up and collects all available KEYMGMT
implementations, and then uses those names to collect deserializer
implementations, as described in the previous commit.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
This adds a method OSSL_DESERIALIZER, a deserializer context and basic
support to use a set of serializers to get a desired type of data, as
well as deserializer chains.
The idea is that the caller can call OSSL_DESERIALIZER_CTX_add_serializer()
to set up the set of desired results, and to add possible chains, call
OSSL_DESERIALIZER_CTX_add_extra(). All these deserializers are pushed
on an internal stack.
The actual deserialization is then performed using functions like
OSSL_DESERIALIZER_from_bio(). When performing deserialization, the
inernal stack is walked backwards, keeping track of the deserialized
data and its type along the way, until the data kan be processed into
the desired type of data.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
This function is used to create a keydata for a key that libcrypto
only has a reference to.
This introduces provider references, the contents which only the
provider know how to interpret. Outside of the provider, this is just
an array of bytes.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
This makes the following functions available for libcrypto code:
evp_keymgmt_util_try_import() - callback function
evp_keymgmt_util_assign_pkey() - assigns keymgmt and keydata to an EVP_PKEY
evp_keymgmt_util_make_pkey() - creates an EVP_PKEY from keymgmt and keydata
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
- In order to not add many X509_XXXX_with_libctx() functions the libctx and propq may be stored in the X509 object via a call to X509_new_with_libctx().
- Loading via PEM_read_bio_X509() or d2i_X509() should pass in a created cert using X509_new_with_libctx().
- Renamed some XXXX_ex() to XXX_with_libctx() for X509 API's.
- Removed the extra parameters in check_purpose..
- X509_digest() has been modified so that it expects a const EVP_MD object() and then internally it does the fetch when it needs to (via ASN1_item_digest_with_libctx()).
- Added API's that set the libctx when they load such as X509_STORE_new_with_libctx() so that the cert chains can be verified.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12153)
The RAND_DRBG callbacks are wrappers around the EVP_RAND callbacks.
During uninstantiation, the EVP_RAND callbacks got lost while the
RAND_DRBG callbacks remained, because RAND_DRBG_uninstantiate()
calls RAND_DRBG_set(), which recreates the EVP_RAND object.
This was causing drbgtest failures.
This commit fixes the problem by adding code to RAND_DRBG_set() for
saving and restoring the EVP_RAND callbacks.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11195)
Fixes#12405Fixes#12377
Calling Init()/Update() and then Init()/Update() again gave a different result when using the same key and iv.
Cipher modes that were using ctx->num were not resetting this value, this includes OFB, CFB & CTR.
The fix is to reset this value during the ciphers einit() and dinit() methods.
Most ciphers go thru a generic method so one line fixes most cases.
Add test for calling EVP_EncryptInit()/EVP_EncryptUpdate() multiple times for all ciphers.
Ciphers should return the same value for both updates.
DES3-WRAP does not since it uses a random in the update.
CCM modes currently also fail on the second update (This also happens in 1_1_1).
Fix memory leak in AES_OCB cipher if EVP_EncryptInit is called multiple times.
Fix AES_SIV cipher dup_ctx and init.
Calling EVP_CIPHER_init multiple times resulted in a memory leak in the siv.
Fixing this leak also showed that the dup ctx was not working for siv mode.
Note: aes_siv_cleanup() can not be used by aes_siv_dupctx() as it clears data
that is required for the decrypt (e.g the tag).
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12413)
As the ERR_raise() is setup at this point returng a range of negative values for errors is not required.
This will need to be revisited if the code ever moves to running from the DEP.
Added a -config option to the fips install so that it can test if a fips module is loadable from configuration.
(The -verify option only uses the generated config, whereas -config uses the normal way of including the generated data via another config file).
Added more failure tests for the raised errors.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12346)
The backend code varies for the different MACs and sometimes sets the output
length, sometimes checks the return pointer and sometimes neither.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12458)
If a presumably self-signed cert is last in chain we verify its signature
only if X509_V_FLAG_CHECK_SS_SIGNATURE is set. Upon this request we do the
signature verification, but not in case it is a (non-conforming) self-issued
CA certificate with a key usage extension that does not include keyCertSign.
Make clear when we must verify the signature of a certificate
and when we must adhere to key usage restrictions of the 'issuing' cert.
Add some comments for making internal_verify() easier to understand.
Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE accordingly.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12375)
The commit claimed to make things more consistent. In fact it makes it
less so. Revert back to the previous namig convention.
This reverts commit 765d04c946.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12186)
The commit claimed to make things more consistent. In fact it makes it
less so. Revert back to the previous namig convention.
This reverts commit d9c2fd51e2.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12186)
