Hakase/openssl-custom
1
0 Fork 0
Code Issues Pull Requests Releases Wiki Activity

Latest update.

Browse Source
This commit is contained in:
Hakase
2020-02-11 23:20:44 +09:00
parent 047a30700b
commit 9dfeec3942
639 changed files with 14024 additions and 31198 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/man7/EVP_KDF-KRB5KDF.pod
-1
View File
@@ -96,7 +96,6 @@ RFC 3961
=head1 SEE ALSO
L<EVP_KDF(3)>,
L<EVP_KDF_CTX_new_id(3)>,
L<EVP_KDF_CTX_free(3)>,
L<EVP_KDF_ctrl(3)>,
L<EVP_KDF_size(3)>,
doc/man7/OSSL_PROVIDER-FIPS.pod
+2 -2
View File
@@ -15,7 +15,7 @@ accredited testing laboratory.
One of the requirements for the FIPS module is self testing. An optional callback
mechanism is available to return information to the user using
L<OSSL_SELF_TEST_set_callback(7)>.
L<OSSL_SELF_TEST_set_callback(3)>.
The OPENSSL FIPS module uses the following mechanism to provide information
about the self tests as they run.
@@ -240,7 +240,7 @@ A simple self test callback is shown below for illustrative purposes.
L<openssl-fipsinstall(1)>,
L<fips_config(5)>,
L<OSSL_SELF_TEST_set_callback(7)>,
L<OSSL_SELF_TEST_set_callback(3)>,
L<OSSL_PARAM(3)>,
L<openssl-core.h(7)>
doc/man7/SM2.pod
+6 -16
View File
@@ -20,25 +20,17 @@ B<SM2> signatures can be generated by using the 'DigestSign' series of APIs, for
instance, EVP_DigestSignInit(), EVP_DigestSignUpdate() and EVP_DigestSignFinal().
Ditto for the verification process by calling the 'DigestVerify' series of APIs.
There are several special steps that need to be done before computing an B<SM2>
signature.
The B<EVP_PKEY> structure will default to using ECDSA for signatures when it is
created. It should be set to B<EVP_PKEY_SM2> by calling:
EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2);
Then an ID should be set by calling:
Before computing an B<SM2> signature, an B<EVP_PKEY_CTX> needs to be created,
and an B<SM2> ID must be set for it, like this:
EVP_PKEY_CTX_set1_id(pctx, id, id_len);
When calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions, a
pre-allocated B<EVP_PKEY_CTX> should be assigned to the B<EVP_MD_CTX>. This is
done by calling:
Before calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions,
that B<EVP_PKEY_CTX> should be assigned to the B<EVP_MD_CTX>, like this:
EVP_MD_CTX_set_pkey_ctx(mctx, pctx);
And normally there is no need to pass a B<pctx> parameter to EVP_DigestSignInit()
There is normally no need to pass a B<pctx> parameter to EVP_DigestSignInit()
or EVP_DigestVerifyInit() in such a scenario.
SM2 can be tested with the L<openssl-speed(1)> application since version 3.0.0.
@@ -52,11 +44,10 @@ a message with the SM2 signature algorithm and the SM3 hash algorithm:
#include <openssl/evp.h>
/* obtain an EVP_PKEY using whatever methods... */
EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2);
mctx = EVP_MD_CTX_new();
pctx = EVP_PKEY_CTX_new(pkey, NULL);
EVP_PKEY_CTX_set1_id(pctx, id, id_len);
EVP_MD_CTX_set_pkey_ctx(mctx, pctx);;
EVP_MD_CTX_set_pkey_ctx(mctx, pctx);
EVP_DigestVerifyInit(mctx, NULL, EVP_sm3(), NULL, pkey);
EVP_DigestVerifyUpdate(mctx, msg, msg_len);
EVP_DigestVerifyFinal(mctx, sig, sig_len)
@@ -64,7 +55,6 @@ a message with the SM2 signature algorithm and the SM3 hash algorithm:
=head1 SEE ALSO
L<EVP_PKEY_CTX_new(3)>,
L<EVP_PKEY_set_alias_type(3)>,
L<EVP_DigestSignInit(3)>,
L<EVP_DigestVerifyInit(3)>,
L<EVP_PKEY_CTX_set1_id(3)>,
doc/man7/openssl-env.pod
+1 -1
View File
@@ -37,7 +37,7 @@ See L<openssl-engine(1)>.
=item B<OPENSSL_MALLOC_FD>, B<OPENSSL_MALLOC_FAILURES>
If built with debugging, this allows memory allocation to fail.
See L<OPENSSSL_malloc(3)>.
See L<OPENSSL_malloc(3)>.
=item B<OPENSSL_MODULES>
doc/man7/passphrase-encoding.pod
+1 -1
View File
@@ -65,7 +65,7 @@ A pass phrase encoded in ISO-8859-2 could very well have a sequence such as
0xC3 0xAF (which is the two characters "LATIN CAPITAL LETTER A WITH BREVE"
and "LATIN CAPITAL LETTER Z WITH DOT ABOVE" in ISO-8859-2 encoding), but would
be misinterpreted as the perfectly valid UTF-8 encoded code point U+00EF (LATIN
SMALL LETTER I WITH DIARESIS) I<if the pass phrase doesn't contain anything that
SMALL LETTER I WITH DIAERESIS) I<if the pass phrase doesn't contain anything that
would be invalid UTF-8>.
A pass phrase that contains this kind of byte sequence will give a different
outcome in OpenSSL 1.1.0 and newer than in OpenSSL older than 1.1.0.
doc/man7/provider-asym_cipher.pod
+4 -4
View File
@@ -47,9 +47,9 @@ for further information.
The asymmetric cipher (OSSL_OP_ASYM_CIPHER) operation enables providers to
implement asymmetric cipher algorithms and make them available to applications
via the API functions L<EVP_PKEY_encrypt_init_ex(3)>, L<EVP_PKEY_encrypt(3)>,
L<EVP_PKEY_decrypt_init_ex(3)>, L<EVP_PKEY_decrypt(3)> (as well
as other related functions).
via the API functions L<EVP_PKEY_encrypt(3)>,
L<EVP_PKEY_decrypt(3)> and
other related functions).
All "functions" mentioned here are passed as function pointers between
F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
@@ -108,7 +108,7 @@ structure for holding context information during an asymmetric cipher operation.
A pointer to this context will be passed back in a number of the other
asymmetric cipher operation function calls.
The parameter I<provctx> is the provider context generated during provider
initialisation (see L<provider(3)>).
initialisation (see L<provider(7)>).
OP_asym_cipher_freectx() is passed a pointer to the provider side asymmetric
cipher context in the I<ctx> parameter.
doc/man7/provider-keyexch.pod
+2 -2
View File
@@ -38,8 +38,8 @@ This documentation is primarily aimed at provider authors. See L<provider(7)>
for further information.
The key exchange (OSSL_OP_KEYEXCH) operation enables providers to implement key
exchange algorithms and make them available to applications via the API
functions L<EVP_PKEY_derive_init_ex(3)>, and L<EVP_PKEY_derive(3)> (as well as
exchange algorithms and make them available to applications via
L<EVP_PKEY_derive(3)> and
other related functions).
All "functions" mentioned here are passed as function pointers between
doc/man7/provider-keymgmt.pod
+176 -127
View File
@@ -14,39 +14,29 @@ provider-keymgmt - The KEYMGMT library E<lt>-E<gt> provider functions
* pointers in OSSL_DISPATCH arrays.
*/
/* Key domain parameter creation and destruction */
void *OP_keymgmt_importdomparams(void *provctx, const OSSL_PARAM params[]);
void *OP_keymgmt_gendomparams(void *provctx, const OSSL_PARAM params[]);
void OP_keymgmt_freedomparams(void *domparams);
/* Key object (keydata) creation and destruction */
void *OP_keymgmt_new(void *provctx);
void OP_keymgmt_free(void *keydata);
/* Key domain parameter export */
int OP_keymgmt_exportdomparams(void *domparams, OSSL_PARAM params[]);
/* Key object information */
int OP_keymgmt_get_params(void *keydata, OSSL_PARAM params[]);
const OSSL_PARAM *OP_keymgmt_gettable_params(void);
/* Key domain parameter discovery */
const OSSL_PARAM *OP_keymgmt_importdomparam_types(void);
const OSSL_PARAM *OP_keymgmt_exportdomparam_types(void);
/* Key object content checks */
int OP_keymgmt_has(void *keydata, int selection);
/* Key domain parameter information */
int OP_keymgmt_get_domparam_params(void *domparams, OSSL_PARAM params[]);
const OSSL_PARAM *OP_keymgmt_gettable_domparam_params(void);
/* Discovery of supported operations */
const char *OP_keymgmt_query_operation_name(int operation_id);
/* Key creation and destruction */
void *OP_keymgmt_importkey(void *provctx, const OSSL_PARAM params[]);
void *OP_keymgmt_genkey(void *provctx,
void *domparams, const OSSL_PARAM genkeyparams[]);
void *OP_keymgmt_loadkey(void *provctx, void *id, size_t idlen);
void OP_keymgmt_freekey(void *key);
/* Key object import and export functions */
int OP_keymgmt_import(int selection, void *keydata, const OSSL_PARAM params[]);
const OSSL_PARAM *OP_keymgmt_import_types, (int selection);
int OP_keymgmt_export(int selection, void *keydata,
OSSL_CALLBACK *param_cb, void *cbarg);
const OSSL_PARAM *OP_keymgmt_export_types(int selection);
/* Key export */
int OP_keymgmt_exportkey(void *key, OSSL_PARAM params[]);
/* Key discovery */
const OSSL_PARAM *OP_keymgmt_importkey_types(void);
const OSSL_PARAM *OP_keymgmt_exportkey_types(void);
/* Key information */
int OP_keymgmt_get_key_params(void *key, OSSL_PARAM params[]);
const OSSL_PARAM *OP_keymgmt_gettable_key_params(void);
/* Key object validation */
int OP_keymgmt_validate(void *keydata, int selection);
/* Discovery of supported operations */
const char *OP_keymgmt_query_operation_name(int operation_id);
@@ -62,8 +52,7 @@ works with in tandem, they must belong to the same provider.
The OpenSSL libraries will ensure that they do.
The primary responsibility of the KEYMGMT operation is to hold the
provider side domain parameters and keys for the OpenSSL library
EVP_PKEY structure.
provider side key data for the OpenSSL library EVP_PKEY structure.
All "functions" mentioned here are passed as function pointers between
F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
@@ -75,117 +64,147 @@ All these "functions" have a corresponding function type definition
named B<OSSL_{name}_fn>, and a helper function to retrieve the
function pointer from a B<OSSL_DISPATCH> element named
B<OSSL_get_{name}>.
For example, the "function" OP_keymgmt_importdomparams() has these:
For example, the "function" OP_keymgmt_new() has these:
typedef void *
(OSSL_OP_keymgmt_importdomparams_fn)(void *provctx,
const OSSL_PARAM params[]);
static ossl_inline OSSL_OP_keymgmt_importdomparams_fn
OSSL_get_OP_keymgmt_importdomparams(const OSSL_DISPATCH *opf);
typedef void *(OSSL_OP_keymgmt_new_fn)(void *provctx);
static ossl_inline OSSL_OP_keymgmt_new_fn
OSSL_get_OP_keymgmt_new(const OSSL_DISPATCH *opf);
B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
macros in L<openssl-core_numbers.h(7)>, as follows:
OP_keymgmt_importdomparams OSSL_FUNC_KEYMGMT_IMPORTDOMPARAMS
OP_keymgmt_gendomparams OSSL_FUNC_KEYMGMT_GENDOMPARAMS
OP_keymgmt_freedomparams OSSL_FUNC_KEYMGMT_FREEDOMPARAMS
OP_keymgmt_exportdomparams OSSL_FUNC_KEYMGMT_EXPORTDOMPARAMS
OP_keymgmt_importdomparam_types OSSL_FUNC_KEYMGMT_IMPORTDOMPARAM_TYPES
OP_keymgmt_exportdomparam_types OSSL_FUNC_KEYMGMT_EXPORTDOMPARAM_TYPES
OP_keymgmt_get_domparam_params OSSL_FUNC_KEYMGMT_GET_DOMPARAM_PARAMS
OP_keymgmt_gettable_domparam_params
OSSL_FUNC_KEYMGMT_GETTABLE_DOMPARAM_PARAMS
OP_keymgmt_new OSSL_FUNC_KEYMGMT_NEW
OP_keymgmt_free OSSL_FUNC_KEYMGMT_FREE
OP_keymgmt_importkey OSSL_FUNC_KEYMGMT_IMPORTKEY
OP_keymgmt_genkey OSSL_FUNC_KEYMGMT_GENKEY
OP_keymgmt_loadkey OSSL_FUNC_KEYMGMT_LOADKEY
OP_keymgmt_freekey OSSL_FUNC_KEYMGMT_FREEKEY
OP_keymgmt_exportkey OSSL_FUNC_KEYMGMT_EXPORTKEY
OP_keymgmt_importkey_types OSSL_FUNC_KEYMGMT_IMPORTKEY_TYPES
OP_keymgmt_exportkey_types OSSL_FUNC_KEYMGMT_EXPORTKEY_TYPES
OP_keymgmt_get_key_params OSSL_FUNC_KEYMGMT_GET_KEY_PARAMS
OP_keymgmt_gettable_key_params OSSL_FUNC_KEYMGMT_GETTABLE_KEY_PARAMS
OP_keymgmt_get_params OSSL_FUNC_KEYMGMT_GET_PARAMS
OP_keymgmt_gettable_params OSSL_FUNC_KEYMGMT_GETTABLE_PARAMS
OP_keymgmt_query_operation_name OSSL_FUNC_KEYMGMT_QUERY_OPERATION_NAME
=head2 Domain Parameter Functions
OP_keymgmt_has OSSL_FUNC_KEYMGMT_HAS
OP_keymgmt_validate OSSL_FUNC_KEYMGMT_VALIDATE
OP_keymgmt_importdomparams() should create a provider side structure
for domain parameters, with values taken from the passed B<OSSL_PARAM>
array I<params>.
OP_keymgmt_import OSSL_FUNC_KEYMGMT_IMPORT
OP_keymgmt_import_types OSSL_FUNC_KEYMGMT_IMPORT_TYPES
OP_keymgmt_export OSSL_FUNC_KEYMGMT_EXPORT
OP_keymgmt_export_types OSSL_FUNC_KEYMGMT_EXPORT_TYPES
OP_keymgmt_gendomparams() should generate domain parameters and create
a provider side structure for them.
Values of the passed B<OSSL_PARAM> array I<params> should be used as
input for parameter generation.
OP_keymgmt_freedomparams() should free the passed provider side domain
parameter structure I<domparams>.
=head2 Key Objects
OP_keymgmt_exportdomparams() should extract values from the passed
provider side domain parameter structure I<domparams> into the passed
B<OSSL_PARAM> I<params>.
Only the values specified in I<params> should be extracted.
A key object is a collection of data for an asymmetric key, and is
represented as I<keydata> in this manual.
OP_keymgmt_importdomparam_types() should return a constant array of
descriptor B<OSSL_PARAM>, for parameters that OP_keymgmt_importdomparams()
The exact contents of a key object are defined by the provider, and it
is assumed that different operations in one and the same provider use
the exact same structure to represent this collection of data, so that
for example, a key object that has been created using the KEYMGMT
interface that we document here can be passed as is to other provider
operations, such as OP_signature_sign_init() (see
L<provider-signature(7)>).
With some of the KEYMGMT functions, it's possible to select a specific
subset of data to handle, governed by the bits in a I<selection>
indicator. The bits are:
=over 4
=item B<OSSL_KEYMGMT_SELECT_PRIVATE_KEY>
Indicating that the private key data in a key object should be
considered.
=item B<OSSL_KEYMGMT_SELECT_PUBLIC_KEY>
Indicating that the public key data in a key object should be
considered.
=item B<OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS>
Indicating that the domain parameters in a key object should be
considered.
=item B<OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS>
Indicating that other parameters in a key object should be
considered.
Other parameters are key parameters that don't fit any other
classification. In other words, this particular selector bit works as
a last resort bit bucket selector.
=back
Some selector bits have also been combined for easier use:
=over 4
=item B<OSSL_KEYMGMT_SELECT_ALL_PARAMETERS>
Indicating that all key object parameters should be considered,
regardless of their more granular classification.
=for comment This should used by EVP functions such as
EVP_PKEY_copy_parameters() and EVP_PKEY_cmp_parameters()
This is a combination of B<OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS> and
B<OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS>.
=for comment If more parameter categories are added, they should be
mentioned here too.
=item B<OSSL_KEYMGMT_SELECT_KEYPAIR>
Indicating that both the whole key pair in a key object should be
considered, i.e. the combination of public and private key.
This is a combination of B<OSSL_KEYMGMT_SELECT_PRIVATE_KEY> and
B<OSSL_KEYMGMT_SELECT_PUBLIC_KEY>.
=item B<OSSL_KEYMGMT_SELECT_ALL>
Indicating that everything in a key object should be considered.
=back
The exact interpretation of those bits or how they combine is left to
each function where you can specify a selector.
=for comment One might think that a combination of bits means that all
the selected data subsets must be considered, but then you have to
consider that when comparing key objects (future function), an
implementation might opt to not compare the private key if it has
compared the public key, since a match of one half implies a match of
the other half.
=head2 Constructing and Destructing Functions
OP_keymgmt_new() should create a provider side key object. The
provider context I<provctx> is passed and may be incorporated in the
key object, but that is not mandatory.
OP_keymgmt_free() should free the passed I<keydata>.
The constructor and destructor are mandatory, a KEYMGMT implementation
without them will not be accepted.
=for comment when new constructors appear, it's sufficient if only one
of them is present. The remark above will have to change to reflect
that.
=head2 Key Object Information Functions
OP_keymgmt_get_params() should extract information data associated
with the given I<keydata>, see L</Information Parameters>.
OP_keymgmt_gettable_params() should return a constant array of
descriptor B<OSSL_PARAM>, for parameters that OP_keymgmt_get_params()
can handle.
OP_keymgmt_exportdomparam_types() should return a constant array of
descriptor B<OSSL_PARAM>, for parameters that can be exported with
OP_keymgmt_exportdomparams().
If OP_keymgmt_gettable_params() is present, OP_keymgmt_get_params()
must also be present.
OP_keymgmt_get_domparam_params() should extract information data
associated with the given I<domparams>,
see L</Information Parameters>.
OP_keymgmt_gettable_domparam_params() should return a constant array
of descriptor B<OSSL_PARAM>, for parameters that
OP_keymgmt_get_domparam_params() can handle.
=head2 Key functions
OP_keymgmt_importkey() should create a provider side structure
for keys, with values taken from the passed B<OSSL_PARAM> array
I<params>.
OP_keymgmt_genkey() should generate keys and create a provider side
structure for them.
Values from the passed domain parameters I<domparams> as well as from
the passed B<OSSL_PARAM> array I<params> should be used as input for
key generation.
OP_keymgmt_loadkey() should return a provider side key structure with
a key loaded from a location known only to the provider, identitified
with the identity I<id> of size I<idlen>.
This identity is internal to the provider and is retrieved from the
provider through other means.
=for comment Right now, OP_keymgmt_loadkey is useless, but will be
useful as soon as we have a OSSL_STORE interface
OP_keymgmt_freekey() should free the passed I<key>.
OP_keymgmt_exportkey() should extract values from the passed
provider side key I<key> into the passed B<OSSL_PARAM> I<params>.
Only the values specified in I<params> should be extracted.
OP_keymgmt_importkey_types() should return a constant array of
descriptor B<OSSL_PARAM>, for parameters that OP_keymgmt_importkey()
can handle.
OP_keymgmt_exportkey_types() should return a constant array of
descriptor B<OSSL_PARAM>, for parameters that can be exported with
OP_keymgmt_exportkeys().
OP_keymgmt_get_key_params() should extract information data associated
with the given I<key>, see L</Information Parameters>.
OP_keymgmt_gettable_key_params() should return a constant array of
descriptor B<OSSL_PARAM>, for parameters that
OP_keymgmt_get_key_params() can handle.
=head2 Supported operations
=head2 Key Object Checking Functions
OP_keymgmt_query_operation_name() should return the name of the
supported algorithm for the operation I<operation_id>. This is
@@ -195,13 +214,43 @@ returns NULL, the caller is free to assume that there's an algorithm
from the same provider, of the same name as the one used to fetch the
keymgmt and try to use that.
OP_keymgmt_has() should check whether the given I<keydata> the subsets
of data indicated by the I<selector>. A combination of several
selector bits must consider all those subsets, not just one. An
implementation is, however, free to consider an empty subset of data
to still be a valid subset.
OP_keymgmt_validate() should check if the I<keydata> contains valid
data subsets indicated by I<selection>. Some combined selections of
data subsets may cause validation of the combined data.
For example, the combination of B<OSSL_KEYMGMT_SELECT_PRIVATE_KEY> and
B<OSSL_KEYMGMT_SELECT_PUBLIC_KEY> (or B<OSSL_KEYMGMT_SELECT_KEYPAIR>
for short) is expected to check that the pairwise consistency of
I<keydata> is valid.
=head2 Key Object Import and Export Functions
OP_keymgmt_import() should import data indicated by I<selection> into
I<keydata> with values taken from the B<OSSL_PARAM> array I<params>.
OP_keymgmt_export() should extract values indicated by I<selection>
from I<keydata>, create an B<OSSL_PARAM> array with them and call
I<param_cb> with that array as well as the given I<cbarg>.
OP_keymgmt_import_types() should return a constant array of descriptor
B<OSSL_PARAM> for data indicated by I<selection>, for parameters that
OP_keymgmt_import() can handle.
OP_keymgmt_export_types() should return a constant array of descriptor
B<OSSL_PARAM> for data indicated by I<selection>, that the
OP_keymgmt_export() callback can expect to receive.
=head2 Information Parameters
See L<OSSL_PARAM(3)> for further details on the parameters structure.
Parameters currently recognised by built-in keymgmt algorithms'
OP_keymgmt_get_domparams_params() and OP_keymgmt_get_key_params()
are:
OP_keymgmt_get_params:
=over 4
@@ -241,7 +290,7 @@ The KEYMGMT interface was introduced in OpenSSL 3.0.
=head1 COPYRIGHT
Copyright 2019 The OpenSSL Project Authors. All Rights Reserved.
Copyright 2019-2020 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
doc/man7/provider-serializer.pod
+3 -3
View File
@@ -127,7 +127,7 @@ formatted data.
With objects that have multiple purposes, this can be used to specify
the purpose type. The currently known use cases are asymmetric keys
and domain parameters, where the type can be one of:
and key parameters, where the type can be one of:
=over 4
@@ -141,9 +141,9 @@ key.
An implementation with that format property value outputs a public
key.
=item domainparams
=item parameters
An implementation with that format property value outputs domain
An implementation with that format property value outputs key
parameters.
=back
doc/man7/provider-signature.pod
+3 -3
View File
@@ -51,9 +51,9 @@ for further information.
The signature (OSSL_OP_SIGNATURE) operation enables providers to implement
signature algorithms and make them available to applications via the API
functions L<EVP_PKEY_sign_init_ex(3)>, L<EVP_PKEY_sign(3)>,
L<EVP_PKEY_verify_init_ex(3)>, L<EVP_PKEY_verify(3)>,
L<EVP_PKEY_verify_recover_init_ex(3)> and L<EVP_PKEY_verify_recover(3)> (as well
functions L<EVP_PKEY_sign(3)>,
L<EVP_PKEY_verify(3)>,
and L<EVP_PKEY_verify_recover(3)> (as well
as other related functions).
All "functions" mentioned here are passed as function pointers between
doc/man7/provider.pod
+1 -3
View File
@@ -217,8 +217,7 @@ When they are used with functions like L<EVP_DigestInit_ex(3)> or
L<EVP_CipherInit_ex(3)>, the actual implementation to be used is
fetched implicitly using default search criteria.
Implicit fetching can also occur with functions such as
L<EVP_PKEY_derive_init_ex(3)> where a NULL algorithm parameter is
Implicit fetching can also occur when a NULL algorithm parameter is
supplied.
In this case an algorithm implementation is implicitly fetched using
default search criteria and an algorithm name that is consistent with
@@ -349,7 +348,6 @@ other providers:
=head1 SEE ALSO
L<EVP_DigestInit_ex(3)>, L<EVP_EncryptInit_ex(3)>,
L<EVP_PKEY_derive_init_ex(3)>,
L<OPENSSL_CTX(3)>,
L<EVP_set_default_properties(3)>,
L<EVP_MD_fetch(3)>,