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)
With capabilities we can query a provider about what it can do.
Initially we support a "TLS-GROUP" capability.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11914)
The binder of the AIX linker needs to be told which functions to call on
loading and initializing a shared object. Therefore another configuration
variable shared_fipsflag is introduced, which is appended to shared_defflag
when the providers/fips module gets configured.
It was suggested to refactor the line in the build file template to become
more generic and less magic. There is, however, currently no suggestion how
to actually achive this, so we leave a TODO comment.
The possible shared_fipsflag must only be appended to the shared_def iff
this code is acting on behalf of the fips provider module build.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11950)
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)
The EVP_KDF_CTX_* functions have been relocated to the EVP_KDF_* namespace
for consistency.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11996)
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)
Discussions are ongoing but the OMC has approved the in-principle addition
of these algorithms to the upcoming FIPS validation.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12020)
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)
Dependencies on generated files must be declared explicitly. When
refactoring the DER code in providers/common/der, a few of those
dependency declaration were omitted, which may lead to build errors in
a parallel build.
Some cleanup and extensive used of build.info variables is done while
at it, to avoid unnecessary repetition.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11906)
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)
The problem encountered is that some arrays were deemed unnecessary by
clang, for example:
providers/common/der/der_rsa.c:424:28: error: variable 'der_aid_sha224Identifier' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static const unsigned char der_aid_sha224Identifier[] = {
^
However, these arrays are used in sizeof() expressions in other parts
of the code that's actually used, making that warning-turned-error a
practical problem. We solve this by making the array non-static,
which guarantees that the arrays will be emitted, even though
unnecessarily. Fortunately, they are very small.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
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)
We separate out the NIST arc OIDs to a separate file, so it can be
re-used, and also the DIGEST OIDs.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
The provider context structure is made to include the following information:
- The core provider handle (first argument to the provider init
function). This handle is meant to be used in all upcalls that need
it.
- A library context, used for any libcrypto calls that need it, done in
the provider itself.
Regarding the library context, that's generally only needed if the
provider makes any libcrypto calls, i.e. is linked with libcrypto. That
happens to be the case for all OpenSSL providers, but is applicable for
other providers that use libcrypto internally as well.
The normal thing to do for a provider init function is to create its own
library context. For a provider that's meant to become a dynamically
loadable module, this is what MUST be done.
However, we do not do that in the default provider; it uses the library
context associated with the core provider handle instead. This is
permissible, although generally discouraged, as long as the provider in
question is guaranteed to be built-in, into libcrypto or into the
application that uses it.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11803)
This started with adding forward declarations of all provider side
interface functions, and fixing all compiler errors.
Furthermore, diminish the faulty assumption that the provider context
is and always will be just a library context. That means adding a
teardown function in all providers that aren't necessarily built into
libcrypto.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11777)
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)
