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)
Benjamin Kaduk [Thu, 2 Jul 2020 21:12:33 +0000 (14:12 -0700)]
Use local IV storage in e_aes_ebc_hmac_sha1.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_sha1.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.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.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 [Sat, 20 Jun 2020 05:31:41 +0000 (22:31 -0700)]
Make GCM providers more generous about fetching IVs
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)
Benjamin Kaduk [Sat, 20 Jun 2020 03:42:29 +0000 (20:42 -0700)]
Add tests for new EVP_CIPHER_CTX IV accessors
Test that EVP_CIPHER_CTX_get_iv() returns the same IV that was
given at initialization time, and that EVP_CIPHER_CTX_get_iv_state()
returns the expected value after performing an encryption operation
(which will differ from the previous value for CBC and OFB modes),
for various modes of AES.
Do this both for the implicit fetch and explicit fetch paths,
at the cost of a slightly more complicated switch statement.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Sat, 20 Jun 2020 01:43:58 +0000 (18:43 -0700)]
Deprecate and replace EVP_CIPHER_CTX_iv()/etc.
The EVP_CIPHER_CTX_iv() family of functions are incompatible with
the libcrypto/provider separation, since the implied API contract
(they are undocumented) involves a pointer into the active cipher
context structure. However, the active IV data in a provider-side
context need not even be in the same address space as libcrypto,
so a replacement API is needed.
The existing functions for accessing the (even the "original") IV had
remained undocumented for quite some time, presumably due to unease
about exposing the internals of the cipher state in such a manner.
Provide more maintainable new APIs for accessing the initial ("oiv") and
current-state ("iv") IV data, that copy the value into a caller-provided
array, eliminating the need to provide a pointer into the internal
cipher context, which accordingly no longer provides the ability to
write to the internal cipher state.
Unfortunately, in order to maintain API compatibility with OpenSSL
1.1.1, the old functionality is still available, but is marked as
deprecated for future removal. This would entail removing the "octet
pointer" parameter access, leaving only the "octet string" parameter
type.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Benjamin Kaduk [Fri, 19 Jun 2020 20:50:22 +0000 (13:50 -0700)]
Support cipher provider "iv state"
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 089cb623be76b88a1eea6fcd135101037661bbc3, 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)
Shane Lontis [Tue, 4 Aug 2020 01:21:21 +0000 (11:21 +1000)]
Add dh_kdf support to provider
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)
README.md: remove incorrect link to openssl.github.io
The link to the OpenSSL Project Pages <openssl.github.io>
actually points to an unfinished draft <mspncp.github.io>.
The original intention of this pet project of mine was to
have a website dedicated to describing the OpenSSL workflow
on GitHub and to answer frequently asked questions related
to pull requests and the review process.
The progress on that project has stalled and I'm not so sure
anymore whether it is good idea to have yet another project
website. In particular since the OpenSSL Wiki has seen some
revival and increased activity caused by the upcoming
OpenSSL 3.0 release.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12361)
Matt Caswell [Tue, 4 Aug 2020 13:43:11 +0000 (14:43 +0100)]
Minimise the size of the macros in kdf_exch.c
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)