1=pod 2 3=head1 NAME 4 5RSA_public_encrypt, RSA_private_decrypt - RSA public key cryptography 6 7=head1 SYNOPSIS 8 9 #include <openssl/rsa.h> 10 11The following functions have been deprecated since OpenSSL 3.0, and can be 12hidden entirely by defining B<OPENSSL_API_COMPAT> with a suitable version value, 13see L<openssl_user_macros(7)>: 14 15 int RSA_public_encrypt(int flen, const unsigned char *from, 16 unsigned char *to, RSA *rsa, int padding); 17 18 int RSA_private_decrypt(int flen, const unsigned char *from, 19 unsigned char *to, RSA *rsa, int padding); 20 21=head1 DESCRIPTION 22 23Both of the functions described on this page are deprecated. 24Applications should instead use L<EVP_PKEY_encrypt_init_ex(3)>, 25L<EVP_PKEY_encrypt(3)>, L<EVP_PKEY_decrypt_init_ex(3)> and 26L<EVP_PKEY_decrypt(3)>. 27 28RSA_public_encrypt() encrypts the B<flen> bytes at B<from> (usually a 29session key) using the public key B<rsa> and stores the ciphertext in 30B<to>. B<to> must point to RSA_size(B<rsa>) bytes of memory. 31 32B<padding> denotes one of the following modes: 33 34=over 4 35 36=item RSA_PKCS1_PADDING 37 38PKCS #1 v1.5 padding. This currently is the most widely used mode. 39However, it is highly recommended to use RSA_PKCS1_OAEP_PADDING in 40new applications. SEE WARNING BELOW. 41 42=item RSA_PKCS1_OAEP_PADDING 43 44EME-OAEP as defined in PKCS #1 v2.0 with SHA-1, MGF1 and an empty 45encoding parameter. This mode is recommended for all new applications. 46 47=item RSA_NO_PADDING 48 49Raw RSA encryption. This mode should I<only> be used to implement 50cryptographically sound padding modes in the application code. 51Encrypting user data directly with RSA is insecure. 52 53=back 54 55When encrypting B<flen> must not be more than RSA_size(B<rsa>) - 11 for the 56PKCS #1 v1.5 based padding modes, not more than RSA_size(B<rsa>) - 42 for 57RSA_PKCS1_OAEP_PADDING and exactly RSA_size(B<rsa>) for RSA_NO_PADDING. 58When a padding mode other than RSA_NO_PADDING is in use, then 59RSA_public_encrypt() will include some random bytes into the ciphertext 60and therefore the ciphertext will be different each time, even if the 61plaintext and the public key are exactly identical. 62The returned ciphertext in B<to> will always be zero padded to exactly 63RSA_size(B<rsa>) bytes. 64B<to> and B<from> may overlap. 65 66RSA_private_decrypt() decrypts the B<flen> bytes at B<from> using the 67private key B<rsa> and stores the plaintext in B<to>. B<flen> should 68be equal to RSA_size(B<rsa>) but may be smaller, when leading zero 69bytes are in the ciphertext. Those are not important and may be removed, 70but RSA_public_encrypt() does not do that. B<to> must point 71to a memory section large enough to hold the maximal possible decrypted 72data (which is equal to RSA_size(B<rsa>) for RSA_NO_PADDING, 73RSA_size(B<rsa>) - 11 for the PKCS #1 v1.5 based padding modes and 74RSA_size(B<rsa>) - 42 for RSA_PKCS1_OAEP_PADDING). 75B<padding> is the padding mode that was used to encrypt the data. 76B<to> and B<from> may overlap. 77 78=head1 RETURN VALUES 79 80RSA_public_encrypt() returns the size of the encrypted data (i.e., 81RSA_size(B<rsa>)). RSA_private_decrypt() returns the size of the 82recovered plaintext. A return value of 0 is not an error and 83means only that the plaintext was empty. 84 85On error, -1 is returned; the error codes can be 86obtained by L<ERR_get_error(3)>. 87 88=head1 WARNINGS 89 90Decryption failures in the RSA_PKCS1_PADDING mode leak information 91which can potentially be used to mount a Bleichenbacher padding oracle 92attack. This is an inherent weakness in the PKCS #1 v1.5 padding 93design. Prefer RSA_PKCS1_OAEP_PADDING. 94 95In OpenSSL before version 3.2.0, both the return value and the length of 96returned value could be used to mount the Bleichenbacher attack. 97Since version 3.2.0, the default provider in OpenSSL does not return an 98error when padding checks fail. Instead it generates a random 99message based on used private 100key and provided ciphertext so that application code doesn't have to implement 101a side-channel secure error handling. 102Applications that want to be secure against side-channel attacks with 103providers that don't implement implicit rejection, still need to 104handle the returned values using side-channel free code. 105Side-channel free handling of the error stack can be performed using 106either a pair of unconditional L<ERR_set_mark(3)> and L<ERR_pop_to_mark(3)> 107calls or by using the L<ERR_clear_error(3)> call. 108 109=head1 CONFORMING TO 110 111SSL, PKCS #1 v2.0 112 113=head1 SEE ALSO 114 115L<ERR_get_error(3)>, L<RAND_bytes(3)>, 116L<RSA_size(3)>, L<EVP_PKEY_decrypt(3)>, L<EVP_PKEY_encrypt(3)> 117 118=head1 HISTORY 119 120Both of these functions were deprecated in OpenSSL 3.0. 121 122=head1 COPYRIGHT 123 124Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved. 125 126Licensed under the Apache License 2.0 (the "License"). You may not use 127this file except in compliance with the License. You can obtain a copy 128in the file LICENSE in the source distribution or at 129L<https://www.openssl.org/source/license.html>. 130 131=cut 132
