Also adds error output tests on loading key files with unsupported algorithms to 30-test_evp.t
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13023)
This stops them leaking into other namespaces in a static build.
They remain internal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13013)
CLA: Permission is granted by the author to the OpenSSL team to use these modifications.
Fixes#12903
Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12923)
ECX_KEY was not meant for public consumption, it was only to be
accessed indirectly via EVP routines. However, we still need internal
access for our decoders.
This partially reverts 7c664b1f1bFixes#12880
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12956)
The original names were more intuitive: the generate_counter counts the
number of generate requests, and the reseed_counter counts the number
of reseedings (of the principal DRBG).
reseed_gen_counter -> generate_counter
reseed_prop_counter -> reseed_counter
This is the anologue to commit 8380f453ec on the 1.1.1 stable branch.
The only difference is that the second renaming has already been reverted
on the master branch.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12941)
rsa_pss_params_30_fromdata() now uses the OSSL_PKEY_PARAM_RSA_DIGEST_PROPS parameter also.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12944)
This only refactors them for the changed API, there's not yet a
separate DER to PEM encoder and therefore no chaining possibility
yet.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12873)
SP800-56Br2 requires support for the RSA primitives for RSASVE generate and recover.
As these are simple KEM operations another operation type has been added that can support future extensions.
Added public functions EVP_PKEY_encapsulate_init(), EVP_PKEY_encapsulate(), EVP_PKEY_decapsulate_init() and EVP_PKEY_decapsulate()
Added EVP_KEM_* functions.
Added OSSL_FUNC_kem_* dispatch functions
Added EVP_PKEY_CTX_set_kem_op() so that different types of KEM can be added in the future. This value must currently be set to
"RSASVE" after EVP_PKEY_encapsulate_init() & EVP_PKEY_decapsulate_init() as there is no default value.
This allows the existing RSA key types, keymanagers, and encoders to be used with the encapsulation operations.
The design of the public API's resulted from contributions from @romen & @levitte.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12750)
The other signature algorithms know how to create their own
AlgorithmIdentifiers, but the EdDSA algorithms missed this.
Fixes#11875
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12884)
For key agreement only NIST curves that have a security strength of 112 bits or more are allowed.
Fixed tests so they obey these restrictions when testing in fips mode.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12745)
In fips mode SHA1 should not be allowed for signing, but may be present for verifying.
Add keysize check.
Add missing 'ossl_unused' to gettable and settable methods.
Update fips related tests that have these restrictions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12745)
Fixes#11622Fixes#12378
Due to a missing else it was setting up the stream for BSAES and then using this incorrect stream with VPAES.
The correct behaviour is not to use VPAES at all in this case.
Also note that the original code in e_aes could set up VPAES and then would overwrite it with the generic implementation.
On a machine that supported both BSAES and VPAES the code was changed locally to force it to run both cases to verify
both paths produce the correct known answers.
Debugged using mageia 7.1, but is also highly likely to fix FreeBSD also.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12887)
Also add more test cases
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12826)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12826)
The functions that check for the provider being runnable are: new, init, final
and dupctx.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
The functions that check for the provider being runnable are: new, gen_init,
gen, gen_set_template, load, has, match, validate, import and export.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
The functions that check for the provider being runnable are: newctx, dupctx,
init, derive and set peer.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
Check for provider being runnable in instantiate, reseed, generate and new calls.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
The encoder implementations were implemented by unnecessarily copying
code into numerous topical source files, making them hard to maintain.
This changes merges all those into two source files, one that encodes
into DER and PEM, the other to text.
Diverse small cleanups are included.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12803)
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 underlying MAC implementations may take ctx params. Therefore we allow
the bridge to pass these through.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12732)
Previously we passed it the data plus mac size. Now we just pass it the
data size. We already know the mac size.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12732)
This commit just moves the TLS1 and above implementation to use the TLS
HMAC implementation in the providers.
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)
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)
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)
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)
Some MAC implementations were available before the current EVP_MAC API. They
were used via EVP_DigestSign*. There exists a bridge between the oldAPI and
the EVP_MAC API however this bridge itself uses a legacy EVP_PKEY_METHOD.
This commit implements the signature functions for the 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/12637)
Some MAC implementations were available before the current EVP_MAC API. They
were used via EVP_DigestSign*. There exists a bridge between the old API and
the EVP_MAC API however this bridge itself uses a legacy EVP_PKEY_METHOD.
This commit implements the key management for provider side bridge without
having to useany legacy code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)
When seeding from a parent DRBG, the pointer to the child is used as
additional data. This triggers static code analysers. Rearrange and
expand the comments to make this more obvious.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12724)
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)
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)
Fixes#12630
ec_import requires domain parameters to be part of the selection.
The public and private serialisers were not selecting the correct flags so the import was failing.
Added a test that uses the base provider so that a export/import happens for serialization.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12681)
TLS1.0 does not have an explicit IV in the record, and therefore we should
not attempt to remove it.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12670)
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)
In the FIPS provider, calling EC_GROUP_cmp() with NULL for the BN_CTX
argument is forbidden. Since that's what ec_match() does, it simply
cannot work in the FIPS provider. Therefore, we allocate a BN_CTX
with the library context asssociated with one of the input keys
(doesn't matter which) and use that.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12677)
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)
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)
The S390x hardware-accelerated cipher implementations keep their IV
state in an internal structure tied to the underlying implementation.
However, the provider itself needs to be able to expose the IV state
to libcrypto when processing the "iv-state" parameter. In the absence
of a S390x hardware-specific get_ctx_params() implementation, be sure
to copy the IV state from the hw-specific structure back to the
generic PROV_CIPHER_CTX object after each cipher operation in order to
synchronize the internal and fetchable state.
[extended tests]
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
The current check for iv_gen and iv_gen_rand only lets you fetch
the IV for the case when it was set internally. It might also make
sense to fetch the IV if one was set at cipher-context creation time,
so switch to checking the iv_state, which should be enough to ensure
that there is valid data in the context to be copied out.
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)
Use proper functions with just a macro wrapper around them to minimise
the amount of code inside the macros. We also update the "settable"
functions now that they take a "provctx" parameter.
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)
Reviewed-by: Matt Caswell <matt@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/12608)
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)
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)
The test added previously used a 16 byte block during the update which does not cause internal buffering in the provider.
Some internal variables related to the buffering were not being cleared in the init, which meant that the second
update would use the buffered data from the first update.
Added test for this scenario with exclusions for ciphers that do not support partial block updates.
Found by guidovranken.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12523)
It should be noted that this may be dodgy if we ever encounter
parameter objects that look like something else. However, experience
with the OSSL_STORE 'file:' loader, which does exactly this kind of
thing, has worked fine so far.
A possibility could be that to decode parameters specifically, we
demand that there's an incoming data type specifying this, which
demands by extension that parameters can only come from a file format
that has the parameter type encoded, such as PEM. This would be a
future effort.
Fixes#12568
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12569)
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)
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)
The reseed counter condition was broken since a93ba40, where the
initial value was wrongly changed from one to zero.
Commit 8bf3665 fixed the initialization, but also adjusted the check,
so the problem remained.
This change restores original (OpenSSL-fips-2_0-stable) behavior.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.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)
This boils down to the operating system sources and RDRAND.
All other sources are not available in the FIPS module.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12325)
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)
Added Algorithm names AES-128-CBC-CTS, AES-192-CBC-CTS and AES-256-CBC-CTS.
CS1, CS2 and CS3 variants are supported.
Only single shot updates are supported.
The cipher returns the mode EVP_CIPH_CBC_MODE (Internally it shares the aes_cbc cipher code). This
would allow existing code that uses AES_CBC to switch to the CTS variant without breaking code that
tests for this mode. Because it shares the aes_cbc code the cts128.c functions could not be used directly.
The cipher returns the flag EVP_CIPH_FLAG_CTS.
EVP_CIPH_FLAG_FIPS & EVP_CIPH_FLAG_NON_FIPS_ALLOW have been deprecated.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12094)
This moves test/ossl_test_endian.h to include/internal/endian.h and
thereby makes the macros in there our standard way to check endianness
in run-time.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/12390)
The following built-in curves do not have an assigned OID:
- Oakley-EC2N-3
- Oakley-EC2N-4
In general we shouldn't assume that an OID is always available.
This commit detects such cases, raises an error and returns appropriate
return values so that the condition can be detected and correctly
handled by the callers, when serializing EC parameters or EC keys with
the default `ec_param_enc:named_curve`.
Fixes#12306
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12313)
EVP_CipherUpdate is supposed to return 1 for success or 0 for error.
However for GCM ciphers it was sometimes returning -1 for error.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
We were not correctly passing the provider ctx down the chain during
initialisation of a new cipher ctx. Instead the provider ctx got set to
NULL.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
Other ciphers return the length of the Payload for TLS as a result of an
EVP_DecryptUpdate() operation - but ChaCha20-Poly1305 did not. We change
it so that it does.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
The previous commits separated out the TLS CBC padding code in libssl.
Now we can use that code to directly support TLS CBC padding and MAC
removal in provided ciphers.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all
functions which are dispatched between the core and providers.
This change includes in particular all up- and downcalls, i.e., the
dispatched functions passed from core to provider and vice versa.
- OSSL_core_ -> OSSL_FUNC_core_
- OSSL_provider_ -> OSSL_FUNC_core_
For operations and their function dispatch tables, the following convention
is used:
Type | Name (evp_generic_fetch(3)) |
---------------------|-----------------------------------|
operation | OSSL_OP_FOO |
function id | OSSL_FUNC_FOO_FUNCTION_NAME |
function "name" | OSSL_FUNC_foo_function_name |
function typedef | OSSL_FUNC_foo_function_name_fn |
function ptr getter | OSSL_FUNC_foo_function_name |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12222)
Move the three different DRBGs to the provider.
As part of the move, the DRBG specific data was pulled out of a common
structure and into their own structures. Only these smaller structures are
securely allocated. This saves quite a bit of secure memory:
+-------------------------------+
| DRBG | Bytes | Secure |
+--------------+-------+--------+
| HASH | 376 | 512 |
| HMAC | 168 | 256 |
| CTR | 176 | 256 |
| Common (new) | 320 | 0 |
| Common (old) | 592 | 1024 |
+--------------+-------+--------+
Bytes is the structure size on the X86/64.
Secure is the number of bytes of secure memory used (power of two allocator).
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)
Also separate out the TSC and RDRAND based sources into their own file in the
seeding subdirectory.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)
The test RNG can provide pre-canned entropy and nonces for testing other
algorithms.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)
When we're fetching an IV, there's no need to enforce that the
provided buffer is exactly the same size as the IV we want to
write into it. This might happen, for example, when
EVP_CIPHER_CTX_iv_noconst() passes sizeof(ctx->iv) (that is,
EVP_MAX_IV_LENGTH) for an AES-GCM cipher that uses a shorter IV.
AES-OCB and CCM were also affected.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12039)
OSSL_CIPHER_PARAM_IV can be accessed both as an octet string and as
an octet pointer (for routines like EVP_CIPHER_CTX_iv() that are
in a nebulous undocumented-and-might-go-away-eventually state),
the latter for when there is need to modify the actual value in
the provider.
Make sure that we consistently try to set it as both the string and pointer
forms (not just octet string) and only fail if neither version succeeds. The
generic cipher get_ctx_params routine was already doing so, but the
AES-variant-, GCM-, and CCM-specific ones were not.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12039)
Renames some "new_ex" functions to "new_with_libctx" and ensures that we
pass around the libctx AND the propq everywhere.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12159)
The previous commits made EVP_PKEY_CTX_[get|set]_group_name work for
EC and DH keys. We now extend this to ECX. Even though that keys with
these key types only have one group we still allow it to be explicitly
set so that we have only one codepath for all keys. Setting the group
name for these types of keys is optional, but if you do so it must have
the correct name.
Additionally we enable parameter generation for these keys. Parameters
aren't actually needed for this key type, but for the same reasons as
above (to ensure a single codepath for users of these algorithms) we
enable it anyway.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11914)
The previous commit added the EVP_PKEY_CTX_[get|set]_group_name
functions to work with EC groups. We now extend that to also work for
DH.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11914)
We rename these function to EVP_PKEY_CTX_get_group_name and
EVP_PKEY_CTX_set_group_name so that they can be used for other algorithms
other than EC.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11914)
For FIPS validation purposes - Automated Cryptographic Validation Protocol (ACVP) tests need to be
performed. (See https://github.com/usnistgov/ACVP). These tests are very similiar to the old CAVS tests.
This PR uses a hardwired subset of these test vectors to perform similiar operations,
to show the usage and prove that the API's are able to perform the required operations.
It may also help with communication with the lab (i.e- The lab could add a test here to show
a unworking use case - which we can then address).
The EVP layer performs these tests instead of calling lower level API's
as was done in the old FOM.
Some of these tests require access to internals that are not normally allowed/required.
The config option 'acvp_tests' (enabled by default) has been added so that this
access may be removed.
The mechanism has been implemented as additional OSSL_PARAM values that can be set and get.
A callback mechanism did not seem to add any additional benefit.
These params will not be added to the gettables lists.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11572)
functions are now EVP_MAC functions, usually with ctx in their names.
Before 3.0 is released, the names are mutable and this prevents more
inconsistencies being introduced.
There are no functional or code changes.
Just the renaming and a little reformatting.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11997)
An ECX key doesn't have any parameters associated with it. Therefore it
always has all the parameters it needs, and the "has" function should
return 1 if asked about parameters. Without this
EVP_PKEY_missing_parameters() fails for ECX keys.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11898)
EVP_PKEY_[get1|set1]_tls_encodedpoint() only worked if an ameth was present
which isn't the case for provided keys. Support has been added to dh,
ec and ecx keys.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11898)
Renamed some values in core_names i.e Some DH specific names were changed to use DH instead of FFC.
Added some strings values related to RSA keys.
Moved set_params related docs out of EVP_PKEY_CTX_ctrl.pod into its own file.
Updated Keyexchange and signature code and docs.
Moved some common DSA/DH docs into a shared EVP_PKEY-FFC.pod.
Moved Ed25519.pod into EVP_SIGNATURE-ED25519.pod and reworked it.
Added some usage examples. As a result of the usage examples the following change was also made:
ec allows OSSL_PKEY_PARAM_USE_COFACTOR_ECDH as a settable gen parameter.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11610)
This splits up all the providers/common/der/*.c.in so the generated
portion is on its own and all related DER writing routines are in
their own files. This also ensures that the DIGEST consstants aren't
reproduced in several files (resulting in symbol clashes).
Finally, the production of OID macros is moved to the generated header
files, allowing other similar macros, or DER constant arrays, to be
built on top of them.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11868)
A provider could be linked against a different version of libcrypto than
the version of libcrypto that loaded the provider. Different versions of
libcrypto could define opaque types differently. It must never occur that
a type created in one libcrypto is used directly by the other libcrypto.
This will cause crashes.
We can "cheat" for "built-in" providers that are part of libcrypto itself,
because we know that the two libcrypto versions are the same - but not for
other providers.
To ensure this does not occur we use different types names for the handful
of opaque types that are passed between the core and providers.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11758)
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)
We want to catch errors in passed parameters early, which requires
kowledge of the ongoing operation. Fortunately, that's possible by
re-using the EVP_PKEY_OP macros in specific init functions.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
Partial Fix for #11648.
Some additional work still needs to be done to support RSA-PSS mode.
RSA legacy digests will be addressed in another PR.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11681)
EVP_PKEY_CTX_gettable_params() was missing code for the keygen operation.
After adding it it was noticed that it is probably not required for this type, so instead
the gen_get_params and gen_gettable_params have been remnoved from the provider interface.
gen_get_params was only implemented for ec to get the curve name. This seems redundant
since normally you would set parameters into the keygen_init() and then generate a key.
Normally you would expect to extract data from the key - not the object that we just set up
to do the keygen.
Added a simple settable and gettable test into a test that does keygen.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11683)
Fixes#11459
It was incorrectly using 8 bytes instead of 16 as the default.
This was verified by expanding the macros used in e_cast.c.
The issue occurs if EVP_CIPHER_CTX_set_key_length() is not called.
evp_test.c hides this issue as it always calls EVP_CIPHER_CTX_set_key_length() before
using EVP_CipherInit_ex(...., key, ..).
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11707)
We had a redundant couple of lines where we exported key data twice.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11635)
At various points we need to be able to retrieve the current library
context so we store it in the ECX_KEY structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11635)
ECX keys can very easily crete the public key from the private key.
Therefore when we import ecx keys it is sufficent to just have the private
key.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11635)
The legacy provider contains assembler references. Most code is automagically pulled in from the libcrypto - but the platform specific assembler functions will not be visible in the symbol table. Copying BNASM and DESASM into liblegacy seems to be a better solution than exposing platform specific function in libcrypto.num.
Added a missing call in the des_cbc code for sparc.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11697)
A small number of files contain references to the "OpenSSL license"
which has been deprecated and replaced by the "Apache License 2.0".
Amend the occurences.
Fixes#11649
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11663)
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)
This adds handling of the parameter "mandatory-digest" and responds
with an empty string, meaning that no digest may be used.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11576)
DH_set0_pqg() is now responsible for caching the nid, q and length.
DH with or without named safe prime groups now default to using the maximum private key length (BN_num_bits(q) - 1)
when generating a DH private key. The code is now shared between fips and non fips mode for DH key generation.
The OSSL_PKEY_PARAM_DH_PRIV_LEN parameter can be used during keygen to override the maximum private key length to be
in the range (2 * strength ... bits(q) - 1). Where the strength depends on the length of p.
Added q = (p - 1) / 2 safe prime BIGNUMS so that the code is data driven (To simplify adding new names).
The BIGNUMS were code generated.
Fix error in documented return value for DH_get_nid
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11562)
Moved some shared FFC code into the FFC files.
Added extra paramgen parameters for seed, gindex.
Fixed bug in ossl_prov util to print bignums.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11303)
In a similar way to commit 76e23fc5 we must ensure that we use a libctx
whenever we call EC_POINT_point2buf because it can end up using crypto
algorithms.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11535)
The cipher_tdes_common causes build failure as being duplicated
in libcrypto static builds.
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11544)
DES implementations were missing the dup/copy ctx routines
required by CMAC implementation. A regression test is added.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11498)
Ed25519 needs to fetch a digest and so needs to use the correct libctx.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11496)
DES, idea, seed, rc2, rc4, rc5, cast and blowfish have been moved out of the default provider.
Code shared between desx and tdes has been moved into a seperate file (cipher_tdes_common.c).
3 test recipes failed due to using app/openssl calls that used legacy ciphers.
These calls have been updated to supply both the default and legacy providers.
Fixed openssl app '-provider' memory leak
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11419)
The exporter freed a buffer too soon, and there were attempts to use
its data later, which was overwritten by something else at that
point.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11358)
In function 'ccm_tls_cipher',
inlined from 'ccm_cipher_internal' at providers/common/ciphers/cipher_ccm.c:359:16,
inlined from 'ccm_stream_final' at providers/common/ciphers/cipher_ccm.c:265:9:
providers/common/ciphers/cipher_ccm.c:317:5: error: argument 2 null where non-null expected [-Werror=nonnull]
317 | memcpy(ctx->iv + EVP_CCM_TLS_FIXED_IV_LEN, in, EVP_CCM_TLS_EXPLICIT_IV_LEN);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/internal/cryptlib.h:14,
from providers/common/include/prov/ciphercommon.h:14,
from providers/common/ciphers/cipher_ccm.c:12:
providers/common/ciphers/cipher_ccm.c: In function 'ccm_stream_final':
/home/ed/gnu/arm-linux-gnueabihf-linux64/arm-linux-gnueabihf/sys-include/string.h:44:14: note: in a call to function 'memcpy' declared here
44 | extern void *memcpy (void *__restrict __dest,
| ^~~~~~
[extended tests]
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10344)
Currently only RSA, EC and ECX are supported (DH and DSA need to be added to the keygen
PR's seperately because the fields supported have changed significantly).
The API's require the keys to be provider based.
Made the keymanagement export and get_params functions share the same code by supplying
support functions that work for both a OSSL_PARAM_BLD as well as a OSSL_PARAM[].
This approach means that complex code is not required to build an
empty OSSL_PARAM[] with the correct sized fields before then doing a second
pass to populate the array.
The RSA factor arrays have been changed to use unique key names to simplify the interface
needed by the user.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11365)
Since this is public, it is best to make the underlying structure opaque.
This means converting from stack allocation to dynamic allocation for all
usages.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/11390)
The catalyst for this is the difficult of passing BNs through the other
OSSL_PARAM APIs.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/11390)
The provider key export functions for EC_KEY assumed that a public key
is always present, and would fail if not. This blocks any attempt to
export a key structure with only domain parameters.
This is similar to earlier work done in EVP_PKEY_ASN1_METHODs.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11394)
Downgrading EVP_PKEYs from containing provider side internal keys to
containing legacy keys demands support in the EVP_PKEY_ASN1_METHOD.
This became a bit elaborate because the code would be almost exactly
the same as the import functions int EVP_KEYMGMT. Therefore, we end
up moving most of the code to common backend support files that can be
used both by legacy backend code and by our providers.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11375)
EVP_PKEY is rather complex, even before provider side keys entered the
stage.
You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE),
keys that had been assigned a type but no data (pk->pkey.ptr == NULL),
and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL).
For provider side keys, the corresponding states weren't well defined,
and the code didn't quite account for all the possibilities.
We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so
they don't exist at all in the FIPS module.
Most of all, code needs to adapt to the case where an EVP_PKEY's
|keymgmt| is non-NULL, but its |keydata| is NULL.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11375)
At various points in crypto/rsa we need to get random numbers. We should
ensure that we use the correct libctx when doing so.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11355)
This is largely based on the existing X25519 and X448 serializers - but
a few adjustments were necessary so that we can identify what type of key
we are using. Previously we used the keylen for this but X25519 and
ED25519 have the same keylen.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11272)
Note: This PR has not attempted to move the curves into the provider dispatch table.
Mappings between the curve name / nid have been added to the inbuilt curve table.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11133)
The provider- manuals are meant to describe the general interface for
their respective operation. This is not the place to describe
implementation specific details.
This change creates a number of doc/man7/EVP_MD manuals, one for each
algorithm or set of algorithms, as well as doc/man7/EVP_MD-common.pod
to describe what's common to them all.
While we're at it, correct the SHA3 settable context params array to
match what's actually settable.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11270)
At the moment we only provider support for these algorithms in the default
provider. These algorithms only support "one shot" EVP_DigestSign() and
EVP_DigestVerify() as per the existing libcrypto versions.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11261)
Avoid function calls we don't need to do.
In 1.1.1 we have:
aes-128-cbc 572267.80k 681197.08k 715430.74k 720508.59k 722359.64k 723004.07k
Current master:
aes-128-cbc 460663.70k 631125.66k 701283.58k 719794.52k 724732.59k 726668.63k
new:
aes-128-cbc 582057.64k 684288.62k 715721.90k 724856.15k 717578.24k 727176.53k
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11102)
Provide EC serializers for text, pem and der.
EC parameters use ANS1 'CHOICE' - which means they are more embedded than other parameters used by
other KEY types (which normally have a SEQUENCE at the top level).
For this reason the ANS1_STRING type that was being passed around has been changed to a void so that the
code can still be shared with EC.
The EC serializer only supports named curves currently.
NOTE the serializer code assumes PKCS8 format - if the older encode methods are needed they will need to be
added in another PR. (Probably when deserialization is considered).
EVP_PKEY_key_fromdata_init was changed from using a keypair selection to all bits of a key. A side effect of this was
that the very restrictive checks in the ecx code needed to be relaxed as it was assuming all selection flags were non
optional. As this is not the case for any other key the code has been modified.
Fixed a bug in legacy_ctrl_str_to_params() - "ecdh_cofactor_mode" was being incorrectly converted to the wrong keyname.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11107)
Provide serializers for X25519 and X448 for text, pem and der. There are
no parameter serializers because there are no parameters for these
algorithms.
Add some documentation about the various import/export types available
Add additional testing for the serializers
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11095)
This includes legacy PSS controls to params conversion, and an attempt
to generalise the parameter names when they are suitable for more than
one operation.
Also added crypto/rsa/rsa_aid.c, containing proper AlgorithmIdentifiers
for known RSA+hash function combinations.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10557)
Use of the low level DH functions has been informally discouraged for a
long time. We now formally deprecate them.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11024)
Use of the low level RSA functions has been informally discouraged for a
long time. We now formally deprecate them.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11063)
For EC keys it is particularly important to avoid leaking the bit length
of the secret scalar.
Key import/export should never leak the bit length of the secret
scalar in the key.
For this reason, on export we use padded BIGNUMs with fixed length,
using the new `ossl_param_bld_push_BN_pad()`.
When importing we also should make sure that, even if short lived,
the newly created BIGNUM is marked with the BN_FLG_CONSTTIME flag as
soon as possible, so that any processing of this BIGNUM might opt for
constant time implementations in the backend.
Setting the BN_FLG_CONSTTIME flag alone is never enough, we also have
to preallocate the BIGNUM internal buffer to a fixed size big enough
that operations performed during the processing never trigger a
realloc which would leak the size of the scalar through memory
accesses.
Fixed length
------------
The order of the large prime subgroup of the curve is our choice for
a fixed public size, as that is generally the upper bound for
generating a private key in EC cryptosystems and should fit all valid
secret scalars.
For padding on export we just use the bit length of the order
converted to bytes (rounding up).
For preallocating the BIGNUM storage we look at the number of "words"
required for the internal representation of the order, and we
preallocate 2 extra "words" in case any of the subsequent processing
might temporarily overflow the order length.
Future work
-----------
To ensure the flag and fixed size preallocation persists upon
`EC_KEY_set_private_key()`, we need to further harden
`EC_KEY_set_private_key()` and `BN_copy()`.
This is done in separate commits.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10631)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10631)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10631)
Embed libctx in dsa and dh objects and cleanup internal methods to not pass libctx (This makes it consistent with the rsa changes)
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10910)
RSA ASYM_CIPHER was already available within the default provider. We
now make it also available from inside the FIPS module.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10881)
Don't attempt to build ecx related source files in a "no-ec" build.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11065)
Use of the low level DSA functions has been informally discouraged for a
long time. We now formally deprecate them.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10977)
When setting up the hash function for DSA signature, the encoded
AlgorithmIdentifier for the DSA+hash combination is queried, but not
stored, which leads to problems when signing ASN.1 items in libcrypto.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11037)
Compile failures were occuring on systems that weren't AESNI capable
because the detection wasn't quite right in a couple of files.
This fixes a run-checker build failure for the 386 compile option.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11022)
The same go for the pairs import + import_types and export + export_types.
This required some additional changes in our KEYMGMT implementations.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11006)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11006)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11006)
Minor fixes to resolve compilation errors with the no-multiblock
Configure option.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11004)
Refactor the DSA SIGNATURE digest setup to be uniform, and to happen
in two places:
1. when given through the digestsign and digestverify inits
2. when given through the set_ctx_params function.
When setting up the digest, we also check that the digest is one of
the officially accepted for DSA.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10947)
Because the libcrypto code has relinquished control of exact words to
express padding mode choices, we re-implement them in the appropriate
provider implementation.
For the sake of legacy controls, we maintain support for the numeric
form of the padding mode, but leave that support otherwise undeclared.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10947)
It turns out this was never necessary, as the implementation should
always check the default digest size anyway.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10947)
The code was calling EVP_MD_meth_free which is incorrect. It should call
EVP_MD_free. It happened to work but by luck rather than design.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10973)
Use of the low level HMAC functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use EVP_MAC_CTX_new(3), EVP_MAC_CTX_free(3),
EVP_MAC_init(3), EVP_MAC_update(3) and EVP_MAC_final(3).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10836)
Use of the low level CMAC functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use EVP_MAC_CTX_new(3), EVP_MAC_CTX_free(3),
EVP_MAC_init(3), EVP_MAC_update(3) and EVP_MAC_final(3).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10836)
Use of the low level DES functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10858)
We've started to see "magic" numbers being used for certain sizes,
such as algorithm names and property query strings.
This change takes care of the few items where buffers for algorithm
names and property query strings are used.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10928)
The common routine ossl_prov_print_labeled_bignum() didn't print the
BIGNUM quite the way it should. It treated the limbs in a big endian
fashion, when they are really organised in a little endian fashion.
Furthermore, we make it inherit the behaviour from the print of legacy
keys, where a number starting with the high bit set gets an extra zero
printed first.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10891)
Libssl uses the null cipher in certain situations. It should be
converted to a provided cipher.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10865)
These were initially added as internal functions only. However they will
also need to be used by libssl as well. Therefore it make sense to move
them into the public API.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10864)
Use of the low level IDEA functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10819)
Use of the low level MD5 functions has been informally discouraged for a long
time. We now formally deprecate them.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10791)
Use of the low level RC5 functions has been informally discouraged for a long
time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10834)
Use of the low level RC4 functions has been informally discouraged for a long
time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10834)
Use of the low level RC2 functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10834)
Use of the low level SEED functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10833)
providers/implementations/ciphers/ciphercommon_gcm_hw.c had an AES
specific GCM update function, while
providers/implementations/ciphers/cipher_aria_gcm_hw.c had the more
general implementation.
This moves them around to have the more general implementation in the
common source, and place the AES specialiation where it belongs.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10783)
Applications should instead use the higher level EVP APIs, e.g.
EVP_Encrypt*() and EVP_Decrypt*().
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10742)
Applications should instead use the higher level EVP APIs, e.g.
EVP_Encrypt*() and EVP_Decrypt*().
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10741)
Use of the low level Whirlpool functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_Digest,
EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10779)
Use of the low level RIPEMD160 functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_Digest,
EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10789)
Applications should instead use the higher level EVP APIs, e.g.
EVP_Encrypt*() and EVP_Decrypt*().
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10740)
A few provider implementations need this to build correctly with a
'no-deprecated' configuration.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10766)
Use of the low level AES functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10580)
Also Add ability for providers to dynamically exclude cipher algorithms.
Cipher algorithms are only returned from providers if their capable() method is either NULL,
or the method returns 1.
This is mainly required for ciphers that only have hardware implementations.
If there is no hardware support, then the algorithm needs to be not available.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10146)
The new serializer code broke no-dh builds so we add some more guards to fix it.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/10644)
The AES_GCM specialisation was defined in the common cipher header
providers/implementations/include/prov/ciphercommon_gcm.h, when it
should in fact be in a local providers/implementations/ciphers/
header.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10606)
The AES_CCM specialisation was defined in the common cipher header
providers/implementations/include/prov/ciphercommon_ccm.h, when it
should in fact be in a local providers/implementations/ciphers/
header.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10606)
Aes-ecb mode can be optimized by inverleaving cipher operation on
several blocks and loop unrolling. Interleaving needs one ideal
unrolling factor, here we adopt the same factor with aes-cbc,
which is described as below:
If blocks number > 5, select 5 blocks as one iteration,every
loop, decrease the blocks number by 5.
If 3 < left blocks < 5 select 3 blocks as one iteration, every
loop, decrease the block number by 3.
If left blocks < 3, treat them as tail blocks.
Detailed implementation will have a little adjustment for squeezing
code space.
With this way, for small size such as 16 bytes, the performance is
similar as before, but for big size such as 16k bytes, the performance
improves a lot, even reaches to 100%, for some arches such as A57,
the improvement even exceeds 100%. The following table will list the
encryption performance data on aarch64, take a72 and a57 as examples.
Performance value takes the unit of cycles per byte, takes the format
as comparision of values. List them as below:
A72:
Before optimization After optimization Improve
evp-aes-128-ecb@16 17.26538237 16.82663866 2.61%
evp-aes-128-ecb@64 5.50528499 5.222637557 5.41%
evp-aes-128-ecb@256 2.632700213 1.908442892 37.95%
evp-aes-128-ecb@1024 1.876102047 1.078018868 74.03%
evp-aes-128-ecb@8192 1.6550392 0.853982929 93.80%
evp-aes-128-ecb@16384 1.636871283 0.847623957 93.11%
evp-aes-192-ecb@16 17.73104961 17.09692468 3.71%
evp-aes-192-ecb@64 5.78984398 5.418545192 6.85%
evp-aes-192-ecb@256 2.872005308 2.081815274 37.96%
evp-aes-192-ecb@1024 2.083226672 1.25095642 66.53%
evp-aes-192-ecb@8192 1.831992057 0.995916251 83.95%
evp-aes-192-ecb@16384 1.821590009 0.993820525 83.29%
evp-aes-256-ecb@16 18.0606306 17.96963317 0.51%
evp-aes-256-ecb@64 6.19651997 5.762465812 7.53%
evp-aes-256-ecb@256 3.176991394 2.24642538 41.42%
evp-aes-256-ecb@1024 2.385991919 1.396018192 70.91%
evp-aes-256-ecb@8192 2.147862636 1.142222597 88.04%
evp-aes-256-ecb@16384 2.131361787 1.135944617 87.63%
A57:
Before optimization After optimization Improve
evp-aes-128-ecb@16 18.61045121 18.36456218 1.34%
evp-aes-128-ecb@64 6.438628994 5.467959461 17.75%
evp-aes-128-ecb@256 2.957452881 1.97238604 49.94%
evp-aes-128-ecb@1024 2.117096219 1.099665054 92.52%
evp-aes-128-ecb@8192 1.868385973 0.837440804 123.11%
evp-aes-128-ecb@16384 1.853078526 0.822420027 125.32%
evp-aes-192-ecb@16 19.07021756 18.50018552 3.08%
evp-aes-192-ecb@64 6.672351486 5.696088921 17.14%
evp-aes-192-ecb@256 3.260427769 2.131449916 52.97%
evp-aes-192-ecb@1024 2.410522832 1.250529718 92.76%
evp-aes-192-ecb@8192 2.17921605 0.973225504 123.92%
evp-aes-192-ecb@16384 2.162250997 0.95919871 125.42%
evp-aes-256-ecb@16 19.3008384 19.12743654 0.91%
evp-aes-256-ecb@64 6.992950658 5.92149541 18.09%
evp-aes-256-ecb@256 3.576361743 2.287619504 56.34%
evp-aes-256-ecb@1024 2.726671027 1.381267599 97.40%
evp-aes-256-ecb@8192 2.493583657 1.110959913 124.45%
evp-aes-256-ecb@16384 2.473916816 1.099967073 124.91%
Change-Id: Iccd23d972e0d52d22dc093f4c208f69c9d5a0ca7
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10518)
The idea to have all these things in providers/common was viable as
long as the implementations was spread around their main providers.
This is, however, no longer the case, so we move the common blocks
closer to the source that use them.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10564)
In TLSv1.2 a pre-master secret value is passed from the client to the
server encrypted using RSA PKCS1 type 2 padding in a ClientKeyExchange
message. As well as the normal formatting rules for RSA PKCA1 type 2
padding TLS imposes some additional rules about what constitutes a well
formed key. Specifically it must be exactly the right length and
encode the TLS version originally requested by the client (as opposed to
the actual negotiated version) in its first two bytes.
All of these checks need to be done in constant time and, if they fail,
then the TLS implementation is supposed to continue anyway with a random
key (and therefore the connection will fail later on). This avoids
padding oracle type attacks.
This commit implements this within the RSA padding code so that we keep
all the constant time padding logic in one place. A later commit will
remove it from libssl.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10411)
This also adds the missing accessor RSA_get0_pss_params(), so those
parameters can be included in the PKCS#8 data structure without
needing to know the inside of the RSA structure.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
To support generic output of public keys wrapped in a X509_PUBKEY,
additional PEM and i2d/d2i routines are added for that type.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
If we call EVP_EncryptUpdate/EVP_DecryptUpdate with length 0 we should
be able to handle it. Most importantly we shouldn't get different
results if we do this compared to if we don't!
An exception is made for CCM mode which has special handling for this in
the low level cipher function.
Fixes#8675
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10530)
EVP_CIPHER_CTX_set_keylen() was succeeding even though a bad key length
is passed to it. This is because the set_ctx_params() were all accepting
this parameter and blindly changing the keylen even though the cipher did
not accept a variable key length. Even removing this didn't entirely
resolve the issue because set_ctx_params() functions succeed even if
passed a parameter they do not recognise.
This should fix various issues found by OSSfuzz/Cryptofuzz.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10449)
Speed test, aes-siv related cases fail on both x86 and arm.
The return value of siv_init() causes this problem, remove
the iv check to fix it.
Verify it locally, the result is pass.
Fixes#10416
Change-Id: If1a18599f3d0f56f22a1ce4f8f114b8db0f68cca
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10419)
Fixes#10438
issue found by clusterfuzz/ossfuzz
The dest was getting a copy of the src structure which contained a pointer that should point to an offset inside itself - because of the copy it was pointing to the original structure.
The setup for a ctx is mainly done by the initkey method in the PROV_CIPHER_HW structure. Because of this it makes sense that the structure should also contain a copyctx method that is use to resolve any pointers that need to be setup.
A dup_ctx has been added to the cipher_enc tests in evp_test. It does a dup after setup and then frees the original ctx. This detects any floating pointers in the duplicated context that were pointing back to the freed ctx.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10443)
Exporting data from a provider owned domainparams or key is quite an
ordeal, with having to figure out what parameter keys an
implementation supports, call the export function a first time to find
out how large each parameter buffer must be, allocate the necessary
space for it, and call the export function again.
So how about letting the export function build up the key data params
and call back with that? This change implements exactly such a
mechanism.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10414)
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9949)
Implement SP800-108 section 5.2 with CMAC support. As a side effect,
enable 5.1 with CMAC and 5.2 with HMAC. Add test vectors from RFC 6803.
Add OSSL_KDF_PARAM_CIPHER and PROV_R_INVALID_SEED_LENGTH.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10143)
Not needed any more, since the presence of the OSSL_FUNC_CIPHER_CIPHER
function is enough to tell that there's a custom cipher function.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10137)
This involves gcm_cipher() (providers/common/ciphers/cipher_gcm.c),
ccm_cipher() (providers/common/ciphers/cipher_ccm.c), and
tdes_wrap_cipher() (providers/common/ciphers/cipher_tdes_wrap.c)
These are generic implementations of the OSSL_FUNC_CIPHER_CIPHER
function, which returned -1 on error when they should return 0.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10137)
The end up in providers/common/include/prov/.
All inclusions are adjusted accordingly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
New name is providers/implementations/include/prov/implementations.h
All inclusions are adapted accordingly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
From providers/{common,default}/ to providers/implementations/
Except for common code, which remains in providers/common/ciphers/.
However, we do move providers/common/include/internal/ciphers/*.h
to providers/common/include/prov/, and adjust all source including
any of those header files.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
From providers/{common,default,legacy}/ to providers/implementations/
However, providers/common/digests/digest_common.c stays where it is,
because it's support code rather than an implementation.
To better support all kinds of implementations with common code, we
add the library providers/libcommon.a. Code that ends up in this
library must be FIPS agnostic.
While we're moving things around, though, we move digestscommon.h
from providers/common/include/internal to providers/common/include/prov,
thereby starting on a provider specific include structure, which
follows the line of thoughts of the recent header file reorganization.
We modify the affected '#include "internal/something.h"' to
'#include "prov/something.h"'.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
