2020-01-29 18:32:32 +08:00
|
|
|
=pod
|
|
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_check, EVP_PKEY_param_check, EVP_PKEY_public_check,
|
|
|
|
|
EVP_PKEY_private_check, EVP_PKEY_pairwise_check
|
|
|
|
|
- key and parameter validation functions
|
|
|
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
|
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
|
|
|
|
|
int EVP_PKEY_check(EVP_PKEY_CTX *ctx);
|
|
|
|
|
int EVP_PKEY_param_check(EVP_PKEY_CTX *ctx);
|
|
|
|
|
int EVP_PKEY_public_check(EVP_PKEY_CTX *ctx);
|
|
|
|
|
int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx);
|
|
|
|
|
int EVP_PKEY_pairwise_check(EVP_PKEY_CTX *ctx);
|
|
|
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
Redesign the KEYMGMT libcrypto <-> provider interface - the basics
The KEYMGMT libcrypto <-> provider interface currently makes a few
assumptions:
1. provider side domain parameters and key data isn't mutable. In
other words, as soon as a key has been created in any (loaded,
imported data, ...), it's set in stone.
2. provider side domain parameters can be strictly separated from the
key data.
This does work for the most part, but there are places where that's a
bit too rigid for the functionality that the EVP_PKEY API delivers.
Key data needs to be mutable to allow the flexibility that functions
like EVP_PKEY_copy_parameters promise, as well as to provide the
combinations of data that an EVP_PKEY is generally assumed to be able
to hold:
- domain parameters only
- public key only
- public key + private key
- domain parameters + public key
- domain parameters + public key + private key
To remedy all this, we:
1. let go of the distinction between domain parameters and key
material proper in the libcrypto <-> provider interface.
As a consequence, functions that still need it gain a selection
argument, which is a set of bits that indicate what parts of the
key object are to be considered in a specific call. This allows
a reduction of very similar functions into one.
2. Rework the libcrypto <-> provider interface so provider side key
objects are created and destructed with a separate function, and
get their data filled and extracted in through import and export.
(future work will see other key object constructors and other
functions to fill them with data)
Fixes #10979
squash! Redesign the KEYMGMT libcrypto <-> provider interface - the basics
Remedy 1 needs a rewrite:
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)
2020-02-03 01:56:07 +08:00
|
|
|
EVP_PKEY_param_check() validates the parameters component of the key
|
2020-01-29 18:32:32 +08:00
|
|
|
given by B<ctx>.
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_public_check() validates the public component of the key given by B<ctx>.
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_private_check() validates the private component of the key given by B<ctx>.
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_pairwise_check() validates that the public and private components have
|
|
|
|
|
the correct mathematical relationship to each other for the key given by B<ctx>.
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_check() validates all components of a key given by B<ctx>.
|
|
|
|
|
|
|
|
|
|
=head1 NOTES
|
|
|
|
|
|
|
|
|
|
Refer to SP800-56A and SP800-56B for rules relating to when these functions
|
|
|
|
|
should be called during key establishment.
|
|
|
|
|
It is not necessary to call these functions after locally calling an approved key
|
|
|
|
|
generation method, but may be required for assurance purposes when receiving
|
|
|
|
|
keys from a third party.
|
|
|
|
|
|
|
|
|
|
In OpenSSL an EVP_PKEY structure containing a private key also contains the
|
|
|
|
|
public key components and parameters (if any). An OpenSSL private key is
|
|
|
|
|
equivalent to what some libraries call a "key pair". A private key can be used
|
|
|
|
|
in functions which require the use of a public key or parameters.
|
|
|
|
|
|
|
|
|
|
=head1 RETURN VALUES
|
|
|
|
|
|
|
|
|
|
All functions return 1 for success or others for failure.
|
|
|
|
|
They return -2 if the operation is not supported for the specific algorithm.
|
|
|
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
|
|
L<EVP_PKEY_CTX_new(3)>,
|
|
|
|
|
L<EVP_PKEY_fromdata(3)>,
|
|
|
|
|
|
|
|
|
|
=head1 HISTORY
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_check(), EVP_PKEY_public_check() and EVP_PKEY_param_check() were added
|
|
|
|
|
in OpenSSL 1.1.1.
|
|
|
|
|
|
|
|
|
|
EVP_PKEY_private_check() and EVP_PKEY_pairwise_check() were added
|
|
|
|
|
in OpenSSL 3.0.
|
|
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
|
|
|
|
|
Copyright 2006-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
|
|
|
|
|
in the file LICENSE in the source distribution or at
|
|
|
|
|
L<https://www.openssl.org/source/license.html>.
|
|
|
|
|
|
|
|
|
|
=cut
|
