negotiated protocol version. Otherwise it should be left unset.
Similarly to the B<RSA_PKCS1_WITH_TLS_PADDING> above, since OpenSSL version
-3.1.0, the use of B<RSA_PKCS1_PADDING> will return a randomly generated message
+3.2.0, the use of B<RSA_PKCS1_PADDING> will return a randomly generated message
instead of padding errors in case padding checks fail. Applications that
want to remain secure while using earlier versions of OpenSSL, still need to
handle both the error code from the RSA decryption operation and the
=head1 WARNINGS
-In OpenSSL versions before 3.1.0, when used in PKCS#1 v1.5 padding,
+In OpenSSL versions before 3.2.0, when used in PKCS#1 v1.5 padding,
both the return value from the EVP_PKEY_decrypt() and the B<outlen> provided
information useful in mounting a Bleichenbacher attack against the
used private key. They had to processed in a side-channel free way.
-Since version 3.1.0, the EVP_PKEY_decrypt() method when used with PKCS#1
+Since version 3.2.0, the EVP_PKEY_decrypt() method when used with PKCS#1
v1.5 padding doesn't return an error in case it detects an error in padding,
instead it returns a pseudo-randomly generated message, removing the need
of side-channel secure code from applications using OpenSSL.
attack. This is an inherent weakness in the PKCS #1 v1.5 padding
design. Prefer RSA_PKCS1_OAEP_PADDING.
-In OpenSSL before version 3.1.0, both the return value and the length of
+In OpenSSL before version 3.2.0, both the return value and the length of
returned value could be used to mount the Bleichenbacher attack.
-Since version 3.1.0, OpenSSL does not return an error in case of padding
+Since version 3.2.0, OpenSSL does not return an error in case of padding
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.