diff options
Diffstat (limited to 'doc/man3/EVP_PKEY_decrypt.pod')
-rw-r--r-- | doc/man3/EVP_PKEY_decrypt.pod | 13 |
1 files changed, 11 insertions, 2 deletions
diff --git a/doc/man3/EVP_PKEY_decrypt.pod b/doc/man3/EVP_PKEY_decrypt.pod index 67e3f2da1e..903d933fb2 100644 --- a/doc/man3/EVP_PKEY_decrypt.pod +++ b/doc/man3/EVP_PKEY_decrypt.pod @@ -56,12 +56,21 @@ algorithm. 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. +used private key. They had to be processed in a side-channel free way. 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, +v1.5 padding as implemented in the B<default> provider implements +the implicit rejection mechanism (see +B<OSSL_PKEY_PARAM_IMPLICIT_REJECTION> in L<provider-asym_cipher(7)>). +That means it doesn't return an error when 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. +If OpenSSL is configured to use a provider that doesn't implement implicit +rejection, the code still needs to handle the returned values +using side-channel free code. +Side-channel free handling of the error stack can be performed using +either a pair of unconditional L<ERR_set_mark(3)> and L<ERR_pop_to_mark(3)> +calls or by using the L<ERR_clear_error(3)> call. =head1 EXAMPLES |