2016-05-03 22:21:41 +08:00
|
|
|
=pod
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
d2i_PrivateKey_ex, d2i_PrivateKey, d2i_PublicKey, d2i_KeyParams,
|
|
|
|
d2i_AutoPrivateKey_ex, d2i_AutoPrivateKey, i2d_PrivateKey, i2d_PublicKey,
|
|
|
|
i2d_KeyParams, i2d_KeyParams_bio, d2i_PrivateKey_ex_bio, d2i_PrivateKey_bio,
|
|
|
|
d2i_PrivateKey_ex_fp, d2i_PrivateKey_fp, d2i_KeyParams_bio, i2d_PrivateKey_bio,
|
|
|
|
i2d_PrivateKey_fp
|
2016-06-08 03:49:08 +08:00
|
|
|
- decode and encode functions for reading and saving EVP_PKEY structures
|
2016-05-03 22:21:41 +08:00
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
EVP_PKEY *d2i_PrivateKey_ex(int type, EVP_PKEY **a, const unsigned char **pp,
|
|
|
|
long length, OPENSSL_CTX *libctx,
|
|
|
|
const char *propq);
|
2016-05-03 22:21:41 +08:00
|
|
|
EVP_PKEY *d2i_PrivateKey(int type, EVP_PKEY **a, const unsigned char **pp,
|
|
|
|
long length);
|
2017-10-08 22:50:38 +08:00
|
|
|
EVP_PKEY *d2i_PublicKey(int type, EVP_PKEY **a, const unsigned char **pp,
|
|
|
|
long length);
|
2019-05-27 19:52:37 +08:00
|
|
|
EVP_PKEY *d2i_KeyParams(int type, EVP_PKEY **a, const unsigned char **pp,
|
|
|
|
long length);
|
2020-04-08 18:54:53 +08:00
|
|
|
EVP_PKEY *d2i_AutoPrivateKey_ex(EVP_PKEY **a, const unsigned char **pp,
|
|
|
|
long length, OPENSSL_CTX *libctx,
|
|
|
|
const char *propq);
|
2016-05-03 22:21:41 +08:00
|
|
|
EVP_PKEY *d2i_AutoPrivateKey(EVP_PKEY **a, const unsigned char **pp,
|
|
|
|
long length);
|
2019-05-27 19:52:37 +08:00
|
|
|
|
2019-01-16 04:51:25 +08:00
|
|
|
int i2d_PrivateKey(const EVP_PKEY *a, unsigned char **pp);
|
|
|
|
int i2d_PublicKey(const EVP_PKEY *a, unsigned char **pp);
|
2019-05-27 19:52:37 +08:00
|
|
|
int i2d_KeyParams(const EVP_PKEY *a, unsigned char **pp);
|
|
|
|
int i2d_KeyParams_bio(BIO *bp, const EVP_PKEY *pkey);
|
2020-04-08 18:54:53 +08:00
|
|
|
EVP_PKEY *d2i_KeyParams_bio(int type, EVP_PKEY **a, BIO *in);
|
|
|
|
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
#include <openssl/x509.h>
|
|
|
|
|
|
|
|
EVP_PKEY *d2i_PrivateKey_ex_bio(BIO *bp, EVP_PKEY **a, OPENSSL_CTX *libctx,
|
|
|
|
const char *propq);
|
2016-06-08 03:49:08 +08:00
|
|
|
EVP_PKEY *d2i_PrivateKey_bio(BIO *bp, EVP_PKEY **a);
|
2020-04-08 18:54:53 +08:00
|
|
|
EVP_PKEY *d2i_PrivateKey_ex_fp(FILE *fp, EVP_PKEY **a, OPENSSL_CTX *libctx,
|
|
|
|
const char *propq);
|
2020-07-15 16:26:35 +08:00
|
|
|
EVP_PKEY *d2i_PrivateKey_fp(FILE *fp, EVP_PKEY **a);
|
2020-04-08 18:54:53 +08:00
|
|
|
|
|
|
|
int i2d_PrivateKey_bio(BIO *bp, const EVP_PKEY *pkey);
|
|
|
|
int i2d_PrivateKey_fp(FILE *fp, const EVP_PKEY *pkey);
|
2016-06-08 03:49:08 +08:00
|
|
|
|
2016-05-03 22:21:41 +08:00
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
d2i_PrivateKey_ex() decodes a private key using algorithm I<type>. It attempts
|
|
|
|
to use any key specific format or PKCS#8 unencrypted PrivateKeyInfo format. The
|
|
|
|
I<type> parameter should be a public key algorithm constant such as
|
|
|
|
B<EVP_PKEY_RSA>. An error occurs if the decoded key does not match I<type>. Some
|
|
|
|
private key decoding implementations may use cryptographic algorithms (for
|
|
|
|
example to automatically derive the public key if it is not explicitly
|
|
|
|
included in the encoding). In this case the supplied library context I<libctx>
|
|
|
|
and property query string I<propq> are used.
|
|
|
|
d2i_PrivateKey() does the same as d2i_PrivateKey_ex() except that the default
|
|
|
|
library context and property query string are used.
|
2017-10-08 22:50:38 +08:00
|
|
|
d2i_PublicKey() does the same for public keys.
|
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
|
|
|
d2i_KeyParams() does the same for key parameters.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
The d2i_PrivateKey_ex_bio() and d2i_PrivateKey_bio() functions are similar to
|
|
|
|
d2i_PrivateKey_ex() and d2i_PrivateKey() respectively except that they decode
|
|
|
|
the data read from the given BIO. The d2i_PrivateKey_ex_fp() and
|
|
|
|
d2i_PrivateKey_fp() functions are the same except that they read the data from
|
|
|
|
the given FILE.
|
|
|
|
|
|
|
|
d2i_AutoPrivateKey_ex() and d2i_AutoPrivateKey() are similar to
|
|
|
|
d2i_PrivateKey_ex() and d2i_PrivateKey() respectively except that they attempt
|
|
|
|
to automatically detect the private key format.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
i2d_PrivateKey() encodes I<a>. It uses a key specific format or, if none is
|
2016-05-03 22:21:41 +08:00
|
|
|
defined for that key type, PKCS#8 unencrypted PrivateKeyInfo format.
|
2017-10-08 22:50:38 +08:00
|
|
|
i2d_PublicKey() does the same for public keys.
|
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
|
|
|
i2d_KeyParams() does the same for key parameters.
|
2016-06-08 03:49:08 +08:00
|
|
|
These functions are similar to the d2i_X509() functions; see L<d2i_X509(3)>.
|
2020-04-08 18:54:53 +08:00
|
|
|
i2d_PrivateKey_bio() and i2d_PrivateKey_fp() do the same thing except that they
|
|
|
|
encode to a B<BIO> or B<FILE> respectrively. Again, these work similarly to the
|
|
|
|
functions described in L<d2i_X509(3)>.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
|
|
|
=head1 NOTES
|
|
|
|
|
|
|
|
All these functions use DER format and unencrypted keys. Applications wishing
|
|
|
|
to encrypt or decrypt private keys should use other functions such as
|
2018-02-16 22:45:32 +08:00
|
|
|
d2i_PKCS8PrivateKey() instead.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
If the I<*a> is not NULL when calling d2i_PrivateKey() or d2i_AutoPrivateKey()
|
2016-05-03 22:21:41 +08:00
|
|
|
(i.e. an existing structure is being reused) and the key format is PKCS#8
|
2020-04-08 18:54:53 +08:00
|
|
|
then I<*a> will be freed and replaced on a successful call.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
To decode a key with type B<EVP_PKEY_EC>, d2i_PublicKey() requires I<*a> to be
|
2019-02-06 22:28:22 +08:00
|
|
|
a non-NULL EVP_PKEY structure assigned an EC_KEY structure referencing the proper
|
|
|
|
EC_GROUP.
|
|
|
|
|
2016-05-03 22:21:41 +08:00
|
|
|
=head1 RETURN VALUES
|
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
The d2i_PrivateKey_ex(), d2i_PrivateKey(), d2i_AutoPrivateKey_ex(),
|
|
|
|
d2i_AutoPrivateKey(), d2i_PrivateKey_ex_bio(), d2i_PrivateKey_bio(),
|
|
|
|
d2i_PrivateKey_ex_fp(), d2i_PrivateKey_fp(), d2i_PublicKey(), d2i_KeyParams()
|
|
|
|
and d2i_KeyParams_bio() functions return a valid B<EVP_KEY> structure or B<NULL>
|
|
|
|
if an error occurs. The error code can be obtained by calling
|
|
|
|
L<ERR_get_error(3)>.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
i2d_PrivateKey(), i2d_PrivateKey_bio(), i2d_PrivateKey_fp(), i2d_PublicKey(),
|
|
|
|
i2d_KeyParams() i2d_KeyParams_bio() return the number of bytes successfully
|
|
|
|
encoded or a negative value if an error occurs. The error code can be obtained
|
|
|
|
by calling L<ERR_get_error(3)>.
|
2016-05-03 22:21:41 +08:00
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
2016-11-11 16:33:09 +08:00
|
|
|
L<crypto(7)>,
|
2017-03-11 21:56:44 +08:00
|
|
|
L<d2i_PKCS8PrivateKey_bio(3)>
|
2016-05-03 22:21:41 +08:00
|
|
|
|
2020-04-08 18:54:53 +08:00
|
|
|
=head1 HISTORY
|
|
|
|
|
|
|
|
d2i_PrivateKey_ex(), d2i_PrivateKey_ex_bio(), d2i_PrivateKey_ex_fp(), and
|
|
|
|
d2i_AutoPrivateKey_ex() were added in OpenSSL 3.0.
|
|
|
|
|
2016-05-18 23:44:05 +08:00
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
2020-04-23 20:55:52 +08:00
|
|
|
Copyright 2017-2020 The OpenSSL Project Authors. All Rights Reserved.
|
2016-05-18 23:44:05 +08:00
|
|
|
|
2018-12-06 21:04:44 +08:00
|
|
|
Licensed under the Apache License 2.0 (the "License"). You may not use
|
2016-05-18 23:44:05 +08:00
|
|
|
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
|