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
|
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
|
|
|
|
|
2020-03-02 21:39:30 +08:00
|
|
|
The functions described here are used to create new keys from user
|
|
|
|
provided key data, such as I<n>, I<e> and I<d> for a minimal RSA
|
|
|
|
keypair.
|
|
|
|
|
2020-06-30 03:13:07 +08:00
|
|
|
These functions use an B<EVP_PKEY_CTX> context, which should primarily
|
2020-03-02 21:39:30 +08:00
|
|
|
be created with L<EVP_PKEY_CTX_new_from_name(3)> or
|
|
|
|
L<EVP_PKEY_CTX_new_id(3)>.
|
|
|
|
|
|
|
|
The exact key data that the user can pass depends on the key type.
|
|
|
|
These are passed as an L<OSSL_PARAM(3)> array.
|
|
|
|
|
2019-10-15 20:50:35 +08:00
|
|
|
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.
|
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.
|
|
|
|
|
2020-03-02 21:39:30 +08:00
|
|
|
EVP_PKEY_fromdata() creates the structure to store key parameters or a
|
|
|
|
key, given data from I<params> and a context that's been initialized with
|
2020-04-16 10:07:26 +08:00
|
|
|
EVP_PKEY_param_fromdata_init() or EVP_PKEY_key_fromdata_init(). The result is
|
|
|
|
written to I<*ppkey>. The parameters that can be used for various types of key
|
|
|
|
are as described by the diverse "Common parameters" sections of the
|
|
|
|
L<B<EVP_PKEY-RSA>(7)|EVP_PKEY-RSA(7)/Common RSA parameters>,
|
|
|
|
L<B<EVP_PKEY-DSA>(7)|EVP_PKEY-DSA(7)/Common DSA & DH parameters>,
|
|
|
|
L<B<EVP_PKEY-DH>(7)|EVP_PKEY-DH(7)/Common DH parameters>,
|
|
|
|
L<B<EVP_PKEY-EC>(7)|EVP_PKEY-EC(7)/Common EC parameters>,
|
|
|
|
L<B<EVP_PKEY-ED448>(7)|EVP_PKEY-ED448(7)/Common X25519, X448, ED25519 and ED448 parameters>,
|
|
|
|
L<B<EVP_PKEY-X25519>(7)|EVP_PKEY-X25519(7)/Common X25519, X448, ED25519 and ED448 parameters>,
|
|
|
|
L<B<EVP_PKEY-X448>(7)|EVP_PKEY-X448(7)/Common X25519, X448, ED25519 and ED448 parameters>,
|
|
|
|
and L<B<EVP_PKEY-ED25519>(7)|EVP_PKEY-ED25519(7)/Common X25519, X448, ED25519 and ED448 parameters> pages.
|
|
|
|
|
|
|
|
=for comment the awful list of links above is made this way so we get nice
|
|
|
|
rendering as a man-page while still getting proper links in HTML
|
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.
|
|
|
|
|
2020-03-02 21:39:30 +08:00
|
|
|
=head1 EXAMPLES
|
|
|
|
|
|
|
|
These examples are very terse for the sake of staying on topic, which
|
|
|
|
is the EVP_PKEY_fromdata() set of functions. In real applications,
|
|
|
|
BIGNUMs would be handled and converted to byte arrays with
|
|
|
|
BN_bn2nativepad(), but that's off topic here.
|
|
|
|
|
|
|
|
=begin comment
|
|
|
|
|
|
|
|
TODO Write a set of cookbook documents and link to them.
|
|
|
|
|
|
|
|
=end comment
|
|
|
|
|
|
|
|
=head2 Creating an RSA keypair using raw key data
|
|
|
|
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These are extremely small to make this example simple. A real
|
|
|
|
* and secure application will not use such small numbers. A real
|
|
|
|
* and secure application is expected to use BIGNUMs, and to build
|
|
|
|
* this array dynamically.
|
|
|
|
*/
|
2020-04-27 17:47:44 +08:00
|
|
|
unsigned long rsa_n = 0xbc747fc5;
|
|
|
|
unsigned long rsa_e = 0x10001;
|
|
|
|
unsigned long rsa_d = 0x7b133399;
|
|
|
|
OSSL_PARAM params[] = {
|
2020-03-02 21:39:30 +08:00
|
|
|
OSSL_PARAM_ulong("n", &rsa_n),
|
|
|
|
OSSL_PARAM_ulong("e", &rsa_e),
|
|
|
|
OSSL_PARAM_ulong("d", &rsa_d),
|
|
|
|
OSSL_PARAM_END
|
|
|
|
};
|
2020-05-08 16:56:14 +08:00
|
|
|
|
2020-03-02 21:39:30 +08:00
|
|
|
int main()
|
|
|
|
{
|
|
|
|
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
|
|
|
|
EVP_PKEY *pkey = NULL;
|
|
|
|
|
|
|
|
if (ctx == NULL
|
|
|
|
|| !EVP_PKEY_key_fromdata_init(ctx)
|
|
|
|
|| !EVP_PKEY_fromdata(ctx, &pkey, params))
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
/* Do what you want with |pkey| */
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 Creating an ECC keypair using raw key data
|
|
|
|
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These arrays represent large numbers, big endian organization.
|
|
|
|
* In a real application, these would probably be bignums that get
|
|
|
|
* converted to the native integer organization with BN_bn2nativepad().
|
|
|
|
* We're not doing that here, since this is not an example of BIGNUM
|
|
|
|
* functionality, but an example of EVP_PKEY_fromdata().
|
|
|
|
*/
|
|
|
|
#ifndef B_ENDIAN
|
|
|
|
# error "We haven't prepared little endian arrays"
|
|
|
|
#endif
|
|
|
|
const unsigned char priv[] = {
|
|
|
|
0xb9, 0x2f, 0x3c, 0xe6, 0x2f, 0xfb, 0x45, 0x68,
|
|
|
|
0x39, 0x96, 0xf0, 0x2a, 0xaf, 0x6c, 0xda, 0xf2,
|
|
|
|
0x89, 0x8a, 0x27, 0xbf, 0x39, 0x9b, 0x7e, 0x54,
|
|
|
|
0x21, 0xc2, 0xa1, 0xe5, 0x36, 0x12, 0x48, 0x5d
|
|
|
|
};
|
|
|
|
const unsigned char pub[] = {
|
|
|
|
0x04, 0xcf, 0x20, 0xfb, 0x9a, 0x1d, 0x11, 0x6c,
|
|
|
|
0x5e, 0x9f, 0xec, 0x38, 0x87, 0x6c, 0x1d, 0x2f,
|
|
|
|
0x58, 0x47, 0xab, 0xa3, 0x9b, 0x79, 0x23, 0xe6,
|
|
|
|
0xeb, 0x94, 0x6f, 0x97, 0xdb, 0xa3, 0x7d, 0xbd,
|
|
|
|
0xe5, 0x26, 0xca, 0x07, 0x17, 0x8d, 0x26, 0x75,
|
|
|
|
0xff, 0xcb, 0x8e, 0xb6, 0x84, 0xd0, 0x24, 0x02,
|
|
|
|
0x25, 0x8f, 0xb9, 0x33, 0x6e, 0xcf, 0x12, 0x16,
|
|
|
|
0x2f, 0x5c, 0xcd, 0x86, 0x71, 0xa8, 0xbf, 0x1a,
|
|
|
|
0x47
|
|
|
|
};
|
|
|
|
const OSSL_PARAM params[] = {
|
|
|
|
OSSL_PARAM_utf8_string("curve-name", "prime256v1"),
|
|
|
|
OSSL_PARAM_BN("priv", priv, sizeof(priv)),
|
|
|
|
OSSL_PARAM_BN("pub", pub, sizeof(pub)),
|
|
|
|
OSSL_PARAM_END
|
|
|
|
};
|
|
|
|
|
|
|
|
int main()
|
|
|
|
{
|
|
|
|
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, "EC", NULL);
|
|
|
|
EVP_PKEY *pkey = NULL;
|
|
|
|
|
|
|
|
if (ctx == NULL
|
|
|
|
|| !EVP_PKEY_key_fromdata_init(ctx)
|
|
|
|
|| !EVP_PKEY_fromdata(ctx, &pkey, params))
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
/* Do what you want with |pkey| */
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 Finding out params for an unknown key type
|
|
|
|
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
|
|
|
/* Program expects a key type as first argument */
|
|
|
|
int main(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, argv[1], NULL);
|
|
|
|
const *OSSL_PARAM *settable_params = NULL;
|
|
|
|
|
|
|
|
if (ctx == NULL
|
|
|
|
|| (settable_params = EVP_PKEY_key_fromdata_settable(ctx)) == NULL)
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
for (; settable_params->key != NULL; settable_params++) {
|
|
|
|
const char *datatype = NULL;
|
|
|
|
|
|
|
|
switch (settable_params->data_type) {
|
|
|
|
case OSSL_PARAM_INTEGER:
|
|
|
|
datatype = "integer";
|
|
|
|
break;
|
|
|
|
case OSSL_PARAM_UNSIGNED_INTEGER:
|
|
|
|
datatype = "unsigned integer";
|
|
|
|
break;
|
|
|
|
case OSSL_PARAM_UTF8_STRING:
|
|
|
|
datatype = "printable string (utf-8 encoding expected)";
|
|
|
|
break;
|
|
|
|
case OSSL_PARAM_UTF8_PTR:
|
|
|
|
datatype = "printable string pointer (utf-8 encoding expected)";
|
|
|
|
break;
|
|
|
|
case OSSL_PARAM_OCTET_STRING:
|
|
|
|
datatype = "octet string";
|
|
|
|
break;
|
|
|
|
case OSSL_PARAM_OCTET_PTR:
|
|
|
|
datatype = "octet string pointer";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
printf("%s : %s ", settable_params->key, datatype);
|
|
|
|
if (settable_params->data_size == 0)
|
|
|
|
printf("(unlimited size)");
|
|
|
|
else
|
|
|
|
printf("(maximum size %zu)", settable_params->data_size);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
The descriptor L<OSSL_PARAM(3)> returned by
|
|
|
|
EVP_PKEY_key_fromdata_settable() may also be used programmatically, for
|
|
|
|
example with L<OSSL_PARAM_allocate_from_text(3)>.
|
|
|
|
|
2019-10-15 20:50:35 +08:00
|
|
|
=head1 SEE ALSO
|
|
|
|
|
2020-03-02 21:39:30 +08:00
|
|
|
L<EVP_PKEY_CTX_new(3)>, L<provider(7)>, L<EVP_PKEY_gettable_params(3)>,
|
2020-04-16 10:07:26 +08:00
|
|
|
L<OSSL_PARAM(3)>,
|
|
|
|
L<EVP_PKEY-RSA(7)>, L<EVP_PKEY-DSA(7)>, L<EVP_PKEY-DH(7)>, L<EVP_PKEY-EC(7)>,
|
|
|
|
L<EVP_PKEY-ED448(7)>, L<EVP_PKEY-X25519(7)>, L<EVP_PKEY-X448(7)>,
|
|
|
|
L<EVP_PKEY-ED25519(7)>
|
2019-10-15 20:50:35 +08:00
|
|
|
|
|
|
|
=head1 HISTORY
|
|
|
|
|
|
|
|
These functions were added in OpenSSL 3.0.
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
2020-04-16 10:07:26 +08:00
|
|
|
Copyright 2019-2020 The OpenSSL Project Authors. All Rights Reserved.
|
2019-10-15 20:50:35 +08:00
|
|
|
|
|
|
|
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
|
|
|
|
|