openssl/doc/man3/RSA_public_encrypt.pod

125 lines
4.4 KiB
Plaintext
Raw Normal View History

2000-01-12 06:35:21 +08:00
=pod
=head1 NAME
RSA_public_encrypt, RSA_private_decrypt - RSA public key cryptography
=head1 SYNOPSIS
#include <openssl/rsa.h>
The following functions have been deprecated since OpenSSL 3.0, and can be
hidden entirely by defining B<OPENSSL_API_COMPAT> with a suitable version value,
see L<openssl_user_macros(7)>:
int RSA_public_encrypt(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
2000-01-12 06:35:21 +08:00
int RSA_private_decrypt(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
2000-01-12 06:35:21 +08:00
=head1 DESCRIPTION
Both of the functions described on this page are deprecated.
Applications should instead use L<EVP_PKEY_encrypt_init_ex(3)>,
L<EVP_PKEY_encrypt(3)>, L<EVP_PKEY_decrypt_init_ex(3)> and
L<EVP_PKEY_decrypt(3)>.
2000-01-12 06:35:21 +08:00
RSA_public_encrypt() encrypts the B<flen> bytes at B<from> (usually a
session key) using the public key B<rsa> and stores the ciphertext in
2000-02-25 22:19:17 +08:00
B<to>. B<to> must point to RSA_size(B<rsa>) bytes of memory.
2000-01-12 06:35:21 +08:00
B<padding> denotes one of the following modes:
=over 4
=item RSA_PKCS1_PADDING
PKCS #1 v1.5 padding. This currently is the most widely used mode.
However, it is highly recommended to use RSA_PKCS1_OAEP_PADDING in
new applications. SEE WARNING BELOW.
2000-01-12 06:35:21 +08:00
=item RSA_PKCS1_OAEP_PADDING
EME-OAEP as defined in PKCS #1 v2.0 with SHA-1, MGF1 and an empty
encoding parameter. This mode is recommended for all new applications.
=item RSA_NO_PADDING
Raw RSA encryption. This mode should I<only> be used to implement
cryptographically sound padding modes in the application code.
Encrypting user data directly with RSA is insecure.
=back
rsa: add implicit rejection in PKCS#1 v1.5 The RSA decryption as implemented before required very careful handling of both the exit code returned by OpenSSL and the potentially returned ciphertext. Looking at the recent security vulnerabilities (CVE-2020-25659 and CVE-2020-25657) it is unlikely that most users of OpenSSL do it correctly. Given that correct code requires side channel secure programming in application code, we can classify the existing RSA decryption methods as CWE-676, which in turn likely causes CWE-208 and CWE-385 in application code. To prevent that, we can use a technique called "implicit rejection". For that we generate a random message to be returned in case the padding check fails. We generate the message based on static secret data (the private exponent) and the provided ciphertext (so that the attacker cannot determine that the returned value is randomly generated instead of result of decryption and de-padding). We return it in case any part of padding check fails. The upshot of this approach is that then not only is the length of the returned message useless as the Bleichenbacher oracle, so are the actual bytes of the returned message. So application code doesn't have to perform any operations on the returned message in side-channel free way to remain secure against Bleichenbacher attacks. Note: this patch implements a specific algorithm, shared with Mozilla NSS, so that the attacker cannot use one library as an oracle against the other in heterogeneous environments. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13817)
2022-03-15 20:58:08 +08:00
When encrypting B<flen> must not be more than RSA_size(B<rsa>) - 11 for the
PKCS #1 v1.5 based padding modes, not more than RSA_size(B<rsa>) - 42 for
RSA_PKCS1_OAEP_PADDING and exactly RSA_size(B<rsa>) for RSA_NO_PADDING.
When a padding mode other than RSA_NO_PADDING is in use, then
RSA_public_encrypt() will include some random bytes into the ciphertext
and therefore the ciphertext will be different each time, even if the
plaintext and the public key are exactly identical.
The returned ciphertext in B<to> will always be zero padded to exactly
RSA_size(B<rsa>) bytes.
B<to> and B<from> may overlap.
2000-01-12 06:35:21 +08:00
RSA_private_decrypt() decrypts the B<flen> bytes at B<from> using the
private key B<rsa> and stores the plaintext in B<to>. B<flen> should
be equal to RSA_size(B<rsa>) but may be smaller, when leading zero
bytes are in the ciphertext. Those are not important and may be removed,
but RSA_public_encrypt() does not do that. B<to> must point
to a memory section large enough to hold the maximal possible decrypted
data (which is equal to RSA_size(B<rsa>) for RSA_NO_PADDING,
RSA_size(B<rsa>) - 11 for the PKCS #1 v1.5 based padding modes and
RSA_size(B<rsa>) - 42 for RSA_PKCS1_OAEP_PADDING).
B<padding> is the padding mode that was used to encrypt the data.
B<to> and B<from> may overlap.
2000-01-12 06:35:21 +08:00
=head1 RETURN VALUES
RSA_public_encrypt() returns the size of the encrypted data (i.e.,
2000-02-25 22:19:17 +08:00
RSA_size(B<rsa>)). RSA_private_decrypt() returns the size of the
recovered plaintext. A return value of 0 is not an error and
means only that the plaintext was empty.
2000-01-12 06:35:21 +08:00
On error, -1 is returned; the error codes can be
obtained by L<ERR_get_error(3)>.
2000-01-12 06:35:21 +08:00
=head1 WARNINGS
Decryption failures in the RSA_PKCS1_PADDING mode leak information
which can potentially be used to mount a Bleichenbacher padding oracle
attack. This is an inherent weakness in the PKCS #1 v1.5 padding
design. Prefer RSA_PKCS1_OAEP_PADDING.
In OpenSSL before version 3.2.0, both the return value and the length of
rsa: add implicit rejection in PKCS#1 v1.5 The RSA decryption as implemented before required very careful handling of both the exit code returned by OpenSSL and the potentially returned ciphertext. Looking at the recent security vulnerabilities (CVE-2020-25659 and CVE-2020-25657) it is unlikely that most users of OpenSSL do it correctly. Given that correct code requires side channel secure programming in application code, we can classify the existing RSA decryption methods as CWE-676, which in turn likely causes CWE-208 and CWE-385 in application code. To prevent that, we can use a technique called "implicit rejection". For that we generate a random message to be returned in case the padding check fails. We generate the message based on static secret data (the private exponent) and the provided ciphertext (so that the attacker cannot determine that the returned value is randomly generated instead of result of decryption and de-padding). We return it in case any part of padding check fails. The upshot of this approach is that then not only is the length of the returned message useless as the Bleichenbacher oracle, so are the actual bytes of the returned message. So application code doesn't have to perform any operations on the returned message in side-channel free way to remain secure against Bleichenbacher attacks. Note: this patch implements a specific algorithm, shared with Mozilla NSS, so that the attacker cannot use one library as an oracle against the other in heterogeneous environments. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13817)
2022-03-15 20:58:08 +08:00
returned value could be used to mount the Bleichenbacher attack.
Since version 3.2.0, OpenSSL does not return an error in case of padding
rsa: add implicit rejection in PKCS#1 v1.5 The RSA decryption as implemented before required very careful handling of both the exit code returned by OpenSSL and the potentially returned ciphertext. Looking at the recent security vulnerabilities (CVE-2020-25659 and CVE-2020-25657) it is unlikely that most users of OpenSSL do it correctly. Given that correct code requires side channel secure programming in application code, we can classify the existing RSA decryption methods as CWE-676, which in turn likely causes CWE-208 and CWE-385 in application code. To prevent that, we can use a technique called "implicit rejection". For that we generate a random message to be returned in case the padding check fails. We generate the message based on static secret data (the private exponent) and the provided ciphertext (so that the attacker cannot determine that the returned value is randomly generated instead of result of decryption and de-padding). We return it in case any part of padding check fails. The upshot of this approach is that then not only is the length of the returned message useless as the Bleichenbacher oracle, so are the actual bytes of the returned message. So application code doesn't have to perform any operations on the returned message in side-channel free way to remain secure against Bleichenbacher attacks. Note: this patch implements a specific algorithm, shared with Mozilla NSS, so that the attacker cannot use one library as an oracle against the other in heterogeneous environments. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13817)
2022-03-15 20:58:08 +08:00
checks failed. Instead it generates a random message based on used private
key and provided ciphertext so that application code doesn't have to implement
a side-channel secure error handling.
2000-01-12 06:35:21 +08:00
=head1 CONFORMING TO
SSL, PKCS #1 v2.0
=head1 SEE ALSO
L<ERR_get_error(3)>, L<RAND_bytes(3)>,
L<RSA_size(3)>
2000-01-12 06:35:21 +08:00
=head1 HISTORY
Both of these functions were deprecated in OpenSSL 3.0.
=head1 COPYRIGHT
Copyright 2000-2021 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