RSAerr(PADDING CHECK) called in success path?

[Matt Caswell]

On 25/09/2019 19:32, Thomas Uban via openssl-users wrote:
> I am using the openssl 3.0.0 library in an embedded environment and added a unit
> test for RSA based on test/rsa_mp_test.c:test_rsa_mp().
> 
> When the test is run, I see:
> 
> 1.      crypto/rsa/rsa_pk1.c:RSA_padding_check_PKCS1_type_2() calls RSAerr()
> just before returning at the bottom of the function in what appears to be the
> success path.
> 
> 2.      crypto/rsa/rsa_ossl.c:rsa_ossl_private_decrypt() calls RSAerr() near the
> bottom of the function, regardless of the value of ‘r’ – so also in what appears
> to be the success path.

These are constant time tricks. The functions must run in the same amount of
time regardless of any errors that may or may not occur. Since the act of adding
an error to the error queue can itself introduce a timing difference we add the
error regardless of success or failure. We then remove it again if we were
actually successful (which is easier to do in constant time) in the next line
using err_clear_last_constant_time().

Matt


> 
>  
> 
> Both errors indicate padding problems for what are presumably good test data. If
> I comment out the rsa_pk1.c case and add if (r < 0) to the rsa_ossl.c case, the
> final comparison in the test indicates that the encrypt/decrypt resulted in the
> original data.
> 
>  
> 
> What am I missing here?
> 
>  
> 
> --tnx
> 
> --tom
> 
>  
> 
>  
> 
>  
>