2006-07-08 00:47:04 +00:00
|
|
|
=pod
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
|
|
|
pkeyutl - public key algorithm utility
|
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
|
|
|
B<openssl> B<pkeyutl>
|
2016-02-05 16:58:45 +00:00
|
|
|
[B<-help>]
|
2006-07-08 00:47:04 +00:00
|
|
|
[B<-in file>]
|
|
|
|
[B<-out file>]
|
|
|
|
[B<-sigfile file>]
|
|
|
|
[B<-inkey file>]
|
2016-02-02 05:37:41 +00:00
|
|
|
[B<-keyform PEM|DER|ENGINE>]
|
2009-04-15 15:27:03 +00:00
|
|
|
[B<-passin arg>]
|
2006-07-08 00:47:04 +00:00
|
|
|
[B<-peerkey file>]
|
2016-02-02 05:37:41 +00:00
|
|
|
[B<-peerform PEM|DER|ENGINE>]
|
2006-07-08 00:47:04 +00:00
|
|
|
[B<-pubin>]
|
|
|
|
[B<-certin>]
|
|
|
|
[B<-rev>]
|
|
|
|
[B<-sign>]
|
|
|
|
[B<-verify>]
|
|
|
|
[B<-verifyrecover>]
|
|
|
|
[B<-encrypt>]
|
|
|
|
[B<-decrypt>]
|
|
|
|
[B<-derive>]
|
2016-03-01 16:29:47 +00:00
|
|
|
[B<-kdf algorithm>]
|
|
|
|
[B<-kdflen length>]
|
2006-07-08 00:47:04 +00:00
|
|
|
[B<-pkeyopt opt:value>]
|
|
|
|
[B<-hexdump>]
|
|
|
|
[B<-asn1parse>]
|
2009-04-15 15:27:03 +00:00
|
|
|
[B<-engine id>]
|
2016-02-08 04:14:12 +00:00
|
|
|
[B<-engine_impl>]
|
2006-07-08 00:47:04 +00:00
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
The B<pkeyutl> command can be used to perform public key operations using
|
|
|
|
any supported algorithm.
|
|
|
|
|
|
|
|
=head1 COMMAND OPTIONS
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2016-02-05 16:58:45 +00:00
|
|
|
=item B<-help>
|
|
|
|
|
|
|
|
Print out a usage message.
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=item B<-in filename>
|
|
|
|
|
|
|
|
This specifies the input filename to read data from or standard input
|
|
|
|
if this option is not specified.
|
|
|
|
|
|
|
|
=item B<-out filename>
|
|
|
|
|
|
|
|
specifies the output filename to write to or standard output by
|
|
|
|
default.
|
|
|
|
|
2016-02-08 04:14:12 +00:00
|
|
|
=item B<-sigfile file>
|
|
|
|
|
|
|
|
Signature file, required for B<verify> operations only
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=item B<-inkey file>
|
|
|
|
|
|
|
|
the input key file, by default it should be a private key.
|
|
|
|
|
2016-02-02 05:37:41 +00:00
|
|
|
=item B<-keyform PEM|DER|ENGINE>
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2016-02-08 04:14:12 +00:00
|
|
|
the key format PEM, DER or ENGINE. Default is PEM.
|
2009-04-15 15:27:03 +00:00
|
|
|
|
|
|
|
=item B<-passin arg>
|
|
|
|
|
|
|
|
the input key password source. For more information about the format of B<arg>
|
2015-08-17 19:21:33 +00:00
|
|
|
see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)>.
|
2009-04-15 15:27:03 +00:00
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
|
|
|
|
=item B<-peerkey file>
|
|
|
|
|
|
|
|
the peer key file, used by key derivation (agreement) operations.
|
|
|
|
|
2016-02-02 05:37:41 +00:00
|
|
|
=item B<-peerform PEM|DER|ENGINE>
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2016-02-08 04:14:12 +00:00
|
|
|
the peer key format PEM, DER or ENGINE. Default is PEM.
|
2006-07-08 00:47:04 +00:00
|
|
|
|
|
|
|
=item B<-pubin>
|
|
|
|
|
2016-05-20 12:11:46 +00:00
|
|
|
the input file is a public key.
|
2006-07-08 00:47:04 +00:00
|
|
|
|
|
|
|
=item B<-certin>
|
|
|
|
|
2016-05-20 12:11:46 +00:00
|
|
|
the input is a certificate containing a public key.
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2006-07-08 10:01:33 +00:00
|
|
|
=item B<-rev>
|
|
|
|
|
|
|
|
reverse the order of the input buffer. This is useful for some libraries
|
|
|
|
(such as CryptoAPI) which represent the buffer in little endian format.
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=item B<-sign>
|
|
|
|
|
|
|
|
sign the input data and output the signed result. This requires
|
|
|
|
a private key.
|
|
|
|
|
|
|
|
=item B<-verify>
|
|
|
|
|
|
|
|
verify the input data against the signature file and indicate if the
|
|
|
|
verification succeeded or failed.
|
|
|
|
|
|
|
|
=item B<-verifyrecover>
|
|
|
|
|
|
|
|
verify the input data and output the recovered data.
|
|
|
|
|
|
|
|
=item B<-encrypt>
|
|
|
|
|
|
|
|
encrypt the input data using a public key.
|
|
|
|
|
|
|
|
=item B<-decrypt>
|
|
|
|
|
|
|
|
decrypt the input data using a private key.
|
|
|
|
|
|
|
|
=item B<-derive>
|
|
|
|
|
|
|
|
derive a shared secret using the peer key.
|
|
|
|
|
2016-03-01 16:29:47 +00:00
|
|
|
=item B<-kdf algorithm>
|
|
|
|
|
2016-03-04 04:30:42 +00:00
|
|
|
Use key derivation function B<algorithm>. The supported algorithms are
|
|
|
|
at present B<TLS1-PRF> and B<HKDF>.
|
2016-06-07 21:03:15 +00:00
|
|
|
Note: additional parameters and the KDF output length will normally have to be
|
2016-03-04 04:30:42 +00:00
|
|
|
set for this to work. See L<EVP_PKEY_HKDF(3)> and L<EVP_PKEY_TLS1_PRF(3)>
|
|
|
|
for the supported string parameters of each algorithm.
|
2016-03-01 16:29:47 +00:00
|
|
|
|
|
|
|
=item B<-kdflen length>
|
|
|
|
|
2016-03-04 04:30:42 +00:00
|
|
|
Set the output length for KDF.
|
2016-03-01 16:29:47 +00:00
|
|
|
|
2016-02-08 04:14:12 +00:00
|
|
|
=item B<-pkeyopt opt:value>
|
|
|
|
|
|
|
|
Public key options specified as opt:value. See NOTES below for more details.
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=item B<-hexdump>
|
|
|
|
|
|
|
|
hex dump the output data.
|
|
|
|
|
|
|
|
=item B<-asn1parse>
|
|
|
|
|
|
|
|
asn1parse the output data, this is useful when combined with the
|
|
|
|
B<-verifyrecover> option when an ASN1 structure is signed.
|
|
|
|
|
2016-02-08 04:14:12 +00:00
|
|
|
=item B<-engine id>
|
|
|
|
|
|
|
|
specifying an engine (by its unique B<id> string) will cause B<pkeyutl>
|
|
|
|
to attempt to obtain a functional reference to the specified engine,
|
|
|
|
thus initialising it if needed. The engine will then be set as the default
|
|
|
|
for all available algorithms.
|
|
|
|
|
|
|
|
=item B<-engine_impl>
|
|
|
|
|
|
|
|
When used with the B<-engine> option, it specifies to also use
|
|
|
|
engine B<id> for crypto operations.
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=back
|
|
|
|
|
|
|
|
=head1 NOTES
|
|
|
|
|
|
|
|
The operations and options supported vary according to the key algorithm
|
|
|
|
and its implementation. The OpenSSL operations and options are indicated below.
|
|
|
|
|
2006-07-08 10:01:33 +00:00
|
|
|
Unless otherwise mentioned all algorithms support the B<digest:alg> option
|
|
|
|
which specifies the digest in use for sign, verify and verifyrecover operations.
|
|
|
|
The value B<alg> should represent a digest name as used in the
|
|
|
|
EVP_get_digestbyname() function for example B<sha1>.
|
2016-02-01 16:14:34 +00:00
|
|
|
This value is used only for sanity-checking the lengths of data passed in to
|
|
|
|
the B<pkeyutl> and for creating the structures that make up the signature
|
|
|
|
(e.g. B<DigestInfo> in RSASSA PKCS#1 v1.5 signatures).
|
|
|
|
In case of RSA, ECDSA and DSA signatures, this utility
|
|
|
|
will not perform hashing on input data but rather use the data directly as
|
|
|
|
input of signature algorithm. Depending on key type, signature type and mode
|
|
|
|
of padding, the maximum acceptable lengths of input data differ. In general,
|
|
|
|
with RSA the signed data can't be longer than the key modulus, in case of ECDSA
|
|
|
|
and DSA the data shouldn't be longer than field size, otherwise it will be
|
|
|
|
silently truncated to field size.
|
|
|
|
|
|
|
|
In other words, if the value of digest is B<sha1> the input should be 20 bytes
|
|
|
|
long binary encoding of SHA-1 hash function output.
|
2006-07-08 10:01:33 +00:00
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=head1 RSA ALGORITHM
|
|
|
|
|
2015-12-07 03:17:15 +00:00
|
|
|
The RSA algorithm generally supports the encrypt, decrypt, sign,
|
|
|
|
verify and verifyrecover operations. However, some padding modes
|
|
|
|
support only a subset of these operations. The following additional
|
|
|
|
B<pkeyopt> values are supported:
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2006-07-08 10:01:33 +00:00
|
|
|
=over 4
|
|
|
|
|
2015-12-07 03:17:15 +00:00
|
|
|
=item B<rsa_padding_mode:mode>
|
2006-07-08 10:01:33 +00:00
|
|
|
|
|
|
|
This sets the RSA padding mode. Acceptable values for B<mode> are B<pkcs1> for
|
|
|
|
PKCS#1 padding, B<sslv23> for SSLv23 padding, B<none> for no padding, B<oaep>
|
|
|
|
for B<OAEP> mode, B<x931> for X9.31 mode and B<pss> for PSS.
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2016-05-20 12:11:46 +00:00
|
|
|
In PKCS#1 padding if the message digest is not set then the supplied data is
|
2006-07-08 10:01:33 +00:00
|
|
|
signed or verified directly instead of using a B<DigestInfo> structure. If a
|
|
|
|
digest is set then the a B<DigestInfo> structure is used and its the length
|
|
|
|
must correspond to the digest type.
|
|
|
|
|
2014-07-01 16:49:20 +00:00
|
|
|
For B<oaep> mode only encryption and decryption is supported.
|
2006-07-08 10:01:33 +00:00
|
|
|
|
|
|
|
For B<x931> if the digest type is set it is used to format the block data
|
|
|
|
otherwise the first byte is used to specify the X9.31 digest ID. Sign,
|
|
|
|
verify and verifyrecover are can be performed in this mode.
|
|
|
|
|
|
|
|
For B<pss> mode only sign and verify are supported and the digest type must be
|
|
|
|
specified.
|
|
|
|
|
|
|
|
=item B<rsa_pss_saltlen:len>
|
|
|
|
|
2006-07-09 16:05:43 +00:00
|
|
|
For B<pss> mode only this option specifies the salt length. Two special values
|
|
|
|
are supported: -1 sets the salt length to the digest length. When signing -2
|
|
|
|
sets the salt length to the maximum permissible value. When verifying -2 causes
|
|
|
|
the salt length to be automatically determined based on the B<PSS> block
|
|
|
|
structure.
|
2006-07-08 10:01:33 +00:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=head1 DSA ALGORITHM
|
|
|
|
|
|
|
|
The DSA algorithm supports signing and verification operations only. Currently
|
|
|
|
there are no additional options other than B<digest>. Only the SHA1
|
|
|
|
digest can be used and this digest is assumed by default.
|
|
|
|
|
|
|
|
=head1 DH ALGORITHM
|
|
|
|
|
|
|
|
The DH algorithm only supports the derivation operation and no additional
|
|
|
|
options.
|
|
|
|
|
|
|
|
=head1 EC ALGORITHM
|
|
|
|
|
|
|
|
The EC algorithm supports sign, verify and derive operations. The sign and
|
|
|
|
verify operations use ECDSA and derive uses ECDH. Currently there are no
|
|
|
|
additional options other than B<digest>. Only the SHA1 digest can be used and
|
|
|
|
this digest is assumed by default.
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2016-08-12 16:27:11 +00:00
|
|
|
=head1 X25519 ALGORITHM
|
|
|
|
|
|
|
|
The X25519 algorithm supports key derivation only. Currently there are no
|
|
|
|
additional options.
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=head1 EXAMPLES
|
|
|
|
|
|
|
|
Sign some data using a private key:
|
|
|
|
|
|
|
|
openssl pkeyutl -sign -in file -inkey key.pem -out sig
|
|
|
|
|
|
|
|
Recover the signed data (e.g. if an RSA key is used):
|
|
|
|
|
|
|
|
openssl pkeyutl -verifyrecover -in sig -inkey key.pem
|
|
|
|
|
|
|
|
Verify the signature (e.g. a DSA key):
|
|
|
|
|
2006-07-08 00:50:25 +00:00
|
|
|
openssl pkeyutl -verify -in file -sigfile sig -inkey key.pem
|
2006-07-08 00:47:04 +00:00
|
|
|
|
2006-07-08 10:01:33 +00:00
|
|
|
Sign data using a message digest value (this is currently only valid for RSA):
|
|
|
|
|
|
|
|
openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256
|
|
|
|
|
|
|
|
Derive a shared secret value:
|
|
|
|
|
|
|
|
openssl pkeyutl -derive -inkey key.pem -peerkey pubkey.pem -out secret
|
|
|
|
|
2016-03-01 16:29:47 +00:00
|
|
|
Hexdump 48 bytes of TLS1 PRF using digest B<SHA256> and shared secret and
|
2016-03-05 06:13:58 +00:00
|
|
|
seed consisting of the single byte 0xFF:
|
2016-03-01 16:29:47 +00:00
|
|
|
|
|
|
|
openssl pkeyutl -kdf TLS1-PRF -kdflen 48 -pkeyopt md:SHA256 \
|
|
|
|
-pkeyopt hexsecret:ff -pkeyopt hexseed:ff -hexdump
|
|
|
|
|
2006-07-08 00:47:04 +00:00
|
|
|
=head1 SEE ALSO
|
2006-07-08 00:50:25 +00:00
|
|
|
|
2015-08-17 19:21:33 +00:00
|
|
|
L<genpkey(1)>, L<pkey(1)>, L<rsautl(1)>
|
2016-03-04 04:30:42 +00:00
|
|
|
L<dgst(1)>, L<rsa(1)>, L<genrsa(1)>,
|
|
|
|
L<EVP_PKEY_HKDF(3)>, L<EVP_PKEY_TLS1_PRF(3)>
|
2016-05-18 14:16:40 +00:00
|
|
|
|
2016-05-18 15:44:05 +00:00
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
|
|
|
Copyright 2006-2016 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
|
|
|
|
Licensed under the OpenSSL license (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
|