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)
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)
* 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)
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)
* 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)
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)
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 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)
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)
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)
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)
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)
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)
Also, document its unusual semantics of resetting the
cipher list (but preserving other configuration).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/7274)
Including the ones that were added in commit
83b0634702 with a note that they "may go
away" and are now deprecated.
Remove the missingcrypto.txt entries for the now-deprecated functions.
[extended tests]
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 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)
A DHX related test has been commented out and TODO(3) added, until DHX is added correctly to a provider.
Added generated files.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11884)
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)
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)
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)
