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)
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)
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)
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)
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)
This allows users of this header file to compile their own code with
the gcc option -Wunused-parameter.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12459)
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)
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 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)
