Richard Levitte [Wed, 22 Jul 2020 13:34:25 +0000 (15:34 +0200)]
CORE: Define provider-native abstract objects
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)
Shane Lontis [Thu, 20 Aug 2020 03:28:11 +0000 (13:28 +1000)]
Fix CMS so that it still works with non fetchable algorithms.
Fixes #12633
For CMS the Gost engine still requires calls to EVP_get_digestbyname() and EVP_get_cipherbyname() when
EVP_MD_fetch() and EVP_CIPHER_fetch() return NULL.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12689)
Richard Levitte [Thu, 20 Aug 2020 07:33:01 +0000 (09:33 +0200)]
Clean away some declarations
dsa_algorithmidentifier_encoding(), ecdsa_algorithmidentifier_encoding(),
rsa_algorithmidentifier_encoding() have been replaced with DER writer
functions, so they aren't useful any more.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12693)
Shane Lontis [Wed, 19 Aug 2020 09:38:03 +0000 (19:38 +1000)]
Fix incorrect selection flags for ec serializer.
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)
Fix mem leaks on PKCS#12 read error in PKCS12_key_gen_{asc,utf8}
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12639)
Richard Levitte [Tue, 18 Aug 2020 19:45:19 +0000 (21:45 +0200)]
TEST: Use PEM_read_bio_PUBKEY_ex() and PEM_read_bio_PrivateKey_ex()
test/evp_test.c and test/sslapitest.c are affected. This allows them
to decode keys found in stanza files via provider decoder implementations
when a library context other than the default should be used.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12673)
Richard Levitte [Tue, 18 Aug 2020 19:38:56 +0000 (21:38 +0200)]
PEM: Add more library context aware PEM readers
PEM_read_bio_PUBKEY_ex() and PEM_read_bio_Parameters_ex() are added to
complete PEM_read_bio_PrivateKey_ex(). They are all refactored to be
wrappers around the same internal function.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12673)
Richard Levitte [Thu, 30 Jul 2020 08:09:43 +0000 (10:09 +0200)]
STORE: Distinguish public keys from private keys
While public keys and private keys use the same type (EVP_PKEY), just
with different contents, callers still need to distinguish between the
two to be able to know what functions to call with them (for example,
to be able to choose between EVP_PKEY_print_private() and
EVP_PKEY_print_public()).
The OSSL_STORE backend knows what it loaded, so it has the capacity to
inform.
Note that the same as usual still applies, that a private key EVP_PKEY
contains the public parts, but not necessarily the other way around.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12673)
Richard Levitte [Thu, 30 Jul 2020 08:14:27 +0000 (10:14 +0200)]
PROV: Fix DSA and DH private key serializers
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)
Richard Levitte [Tue, 18 Aug 2020 18:39:45 +0000 (20:39 +0200)]
X509: Add d2i_PUBKEY_ex(), which take a libctx and propq
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)
Richard Levitte [Tue, 18 Aug 2020 21:13:29 +0000 (23:13 +0200)]
PROV: Fix EC OSSL_FUNC_keymgmt_match() to work in the FIPS provider
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)
Richard Levitte [Tue, 18 Aug 2020 21:00:24 +0000 (23:00 +0200)]
RSA: Fix rsa_todata() to only add params for existing data
The RSA key could be a public key, and yet, rsa_todata() always tries
to add the private parts as well. The resulting parameters will look
a bit odd, such as a zero |d|, resulting in an invalid key.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12676)
Richard Levitte [Tue, 18 Aug 2020 19:17:58 +0000 (21:17 +0200)]
TEST: separate out NIST ECC tests from non-NIST
ECC keys with non-NIST group names aren't supported when running with
the FIPS provider.
Keys with such groups that are included in evp_test stanza files
aren't even possible to decode if provider side decoders are used,
since those depend on available EVP_KEYMGMT implementations and what
they support.
Those keys could only be decoded because the legacy decoders were
used.
To make these tests future proof, we separate out the stanzas having
keys with NIST approved group names into separate files, and adjust
the file lists in test/recipes/30-test_evp.t aaccordingly.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12672)
Richard Levitte [Fri, 7 Aug 2020 16:47:04 +0000 (18:47 +0200)]
EVP: Have evp_pkey_cmp_any() detect if export wasn't possible
There are some EC keys that can't be exported to provider keymgmt,
because the keymgmt implementation doesn't support certain forms of EC
keys. This could lead to a crash caused by dereferencing a NULL
pointer, so we need to cover that case by returning an error instead.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12610)
OSSL_STORE file_load_try_decode(): Avoid flooding error queue by failed tries
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12645)
Shane Lontis [Wed, 19 Aug 2020 03:27:31 +0000 (13:27 +1000)]
Fix no-cms build errors.
Fixes #12640
The X942-KDF is now indepedent of the CMS code (since it no longer uses CMS_SharedInfo_encode).
Any code related to EVP_PKEY_DH_KDF_X9_42 needs to not be wrapped by !defined(OPENSSL_NO_CMS).
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12642)
Shane Lontis [Tue, 11 Aug 2020 00:15:28 +0000 (10:15 +1000)]
Fix DSA/DH so that legacy keys can still be generated by the default provider
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)
Shane Lontis [Mon, 17 Aug 2020 02:34:17 +0000 (12:34 +1000)]
Fix broken windows builds.
A miscellaneous '\' was accidently added to set FIPSKEY=$(FIPSKEY) which was causing some
external CI build loops to not produce test results.
It looks like it was accidently copied from the unix variant which requires the '\'.
Thanks to Wolfgang Beck for tracking down the issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12661)
Pauli [Thu, 13 Aug 2020 00:02:01 +0000 (10:02 +1000)]
provider: disable fall-backs if OSSL_PROVIDER_load() fails.
If an attempt is made to load a provider and it fails, the fall-back mechanism
should be disabled to prevent the user getting some weird happening. E.g. a
failure to load the FIPS provider should not allow the default to load as a
fall-back.
The OSSL_PROVIDER_try_load() call has been added, to allow a provider to be
loaded without disabling the fall-back mechanism if it fails.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12625)
Patrick Steuer [Tue, 11 Aug 2020 11:51:04 +0000 (13:51 +0200)]
Appease -Werror=stringop-overflow=
gcc 10 seems to think of assigning to an (unsigned) char
array as a stringop and demands additional space for a
terminating '\0':
In function 'ssl3_generate_key_block',
inlined from 'ssl3_setup_key_block' at ssl/s3_enc.c:304:11:
ssl/s3_enc.c:51:20: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
51 | buf[j] = c;
| ~~~~~~~^~~
ssl/s3_enc.c: In function 'ssl3_setup_key_block':
ssl/s3_enc.c:23:19: note: at offset 16 to object 'buf' with size 16
declared here
23 | unsigned char buf[16], smd[SHA_DIGEST_LENGTH];
| ^~~
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12632)
Benjamin Kaduk [Thu, 20 Sep 2018 02:14:04 +0000 (21:14 -0500)]
Mark SSL_CTX_set_ssl_version() as deprecated in 3.0
Also, document its unusual semantics of resetting the
cipher list (but preserving other configuration).
Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/7274)
Shane Lontis [Mon, 10 Aug 2020 00:16:26 +0000 (10:16 +1000)]
Fix serializer_EVP_PKEY_to_bio so that that the key is exported if the serializer provider does not match the key provider.
RSA keys in the 'base' provider are different from a fips provider RSA key (since they have different object structures).
To use a fips provider key in the base serializer the key needs to be exported.
The fix was suggested by @levitte.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12162)
Benjamin Kaduk [Tue, 21 Jul 2020 23:23:19 +0000 (16:23 -0700)]
Expose S390x HW ciphers' IV state to provider layer
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)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in EVP BLOCK_* macros
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in evp.h.
These macros are internal-only, used to implement legacy libcrypto
EVP ciphers, with no real provider involvement. Accordingly, just use the
EVP_CIPHER_CTX storage directly and don't try to reach into a provider-side
context.
This does necessitate including evp_local.h in several more files.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_rc2.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_rc2.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_xcbc_d.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_xcbc_d.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_sm4.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_sm4.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_des3.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_des3.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_des.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_des.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_camellia.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_camellia.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_aria.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_aria.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_aes_ebc_hmac_sha256.c
Inline the pre-13273237a65d46186b6bea0b51aec90670d4598a versions
of EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_original_iv(), and
EVP_CIPHER_CTX_iv_noconst() in e_aes_cbc_hmac_sha256.c.
For the legacy implementations, there's no need to use an
in-provider storage for the IV, when the crypto operations
themselves will be performed outside of the provider.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
projects / thirdparty / openssl.git / log
