mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2025-02-17 14:32:04 +08:00
Code Issues Packages Projects Releases Wiki Activity
10d756a70e
openssl/doc/man3/EVP_PKEY_fromdata.pod

72 lines
2.4 KiB
Plaintext
Raw Normal View History

Add EVP functionality to create domain params and keys by user data This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-10-15 20:50:35 +08:00
=pod
=head1 NAME
EVP_PKEY_param_fromdata_init, EVP_PKEY_key_fromdata_init, EVP_PKEY_fromdata,
EVP_PKEY_param_fromdata_settable, EVP_PKEY_key_fromdata_settable
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
- functions to create key parameters and keys from user data
Add EVP functionality to create domain params and keys by user data This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-10-15 20:50:35 +08:00
=head1 SYNOPSIS
#include <openssl/evp.h>
int EVP_PKEY_param_fromdata_init(EVP_PKEY_CTX *ctx);
int EVP_PKEY_key_fromdata_init(EVP_PKEY_CTX *ctx);
int EVP_PKEY_fromdata(EVP_PKEY_CTX *ctx, EVP_PKEY **ppkey, OSSL_PARAM params[]);
const OSSL_PARAM *EVP_PKEY_param_fromdata_settable(EVP_PKEY_CTX *ctx);
const OSSL_PARAM *EVP_PKEY_key_fromdata_settable(EVP_PKEY_CTX *ctx);
=head1 DESCRIPTION
EVP_PKEY_param_fromdata_init() initializes a public key algorithm context
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
for creating key parameters from user data.
Add EVP functionality to create domain params and keys by user data This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-10-15 20:50:35 +08:00
EVP_PKEY_key_fromdata_init() initializes a public key algorithm context for
creating a key from user data.
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_fromdata() creates key parameters or a key, given data from
Add EVP functionality to create domain params and keys by user data This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-10-15 20:50:35 +08:00
I<params> and a context that's been initialized with
EVP_PKEY_param_fromdata_init() or EVP_PKEY_key_fromdata_init(). The result is
Implement the ECX Serializers 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)
2020-02-28 06:08:59 +08:00
written to I<*ppkey>. The parameters that can be used for various types of key
are as described in the "Built-in RSA Import/Export Types" section on the
L<provider-keymgmt(7)> page.
Add EVP functionality to create domain params and keys by user data This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-10-15 20:50:35 +08:00
EVP_PKEY_param_fromdata_settable() and EVP_PKEY_key_fromdata_settable()
get a constant B<OSSL_PARAM> array that describes the settable parameters
that can be used with EVP_PKEY_fromdata().
See L<OSSL_PARAM(3)> for the use of B<OSSL_PARAM> as parameter descriptor.
=head1 NOTES
These functions only work with key management methods coming from a
provider.
=for comment We may choose to make this available for legacy methods too...
=head1 RETURN VALUES
EVP_PKEY_key_fromdata_init(), EVP_PKEY_param_fromdata_init() and
EVP_PKEY_fromdata() return 1 for success and 0 or a negative value for
failure. In particular a return value of -2 indicates the operation is
not supported by the public key algorithm.
=head1 SEE ALSO
Add EVP_PKEY_gettable_params support for accessing EVP_PKEY key data fields 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)
2020-04-01 13:51:18 +08:00
L<EVP_PKEY_CTX_new(3)>, L<provider(7)>, L<EVP_PKEY_gettable_params(3)>
Add EVP functionality to create domain params and keys by user data This is the EVP operation that corresponds to creating direct RSA, DH and DSA keys and set their numbers, to then assign them to an EVP_PKEY, but done entirely using an algorithm agnostic EVP interface. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10187)
2019-10-15 20:50:35 +08:00
=head1 HISTORY
These functions were added in OpenSSL 3.0.
=head1 COPYRIGHT
Copyright 2019 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
Reference in New Issue Copy Permalink