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)
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)
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 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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
