7
$\begingroup$

Is there a way to calculate how much safer RSA-OAEP is compared to RSA with PKCS#1 v1.5 compliant padding? Or is there a good rule of thumb?

$\endgroup$
3
  • 4
    $\begingroup$ 'Just RSA'; is that raw RSA with no padding whatsoever? $\endgroup$
    – poncho
    May 15 '17 at 18:26
  • $\begingroup$ Analogy: Imagine RSA as a wooden beam. It looks nice and solid and is a nice building block, but won't do anything by itself. Now imagine the OAEP padding to be the nails / screws. Now you can do more sensible stuff with it. $\endgroup$
    – SEJPM
    May 15 '17 at 18:31
  • $\begingroup$ @poncho With PKCS#1 v1.5 padding, didn't realize there was still padding by default in openssl $\endgroup$ May 15 '17 at 18:31
12
$\begingroup$

RSA PKCS#1 is still secure if padding oracles do not apply. If padding oracles apply, for instance when a server verifies the padding after decryption and somehow leaks the result (through an error message or by leaking information about the the verification time) then OAEP is much more secure.

Note that in principle OAEP can also leak information through timing attacks, so just using OAEP is no panacea.


[EDIT] Another problem with PKCS#1 v1.5 is that it allows for a relatively small amount of randomness - 8 bytes in the range 1..255 - to be used for larger messages. This can be avoided by using hybrid cryptography (where a symmetric cipher actually encrypts the message) or simply by using smaller messages. However, the MGF1 function of OAEP should be better protected against abuse.


Furthermore, OAEP also has a security proof that the padding should be secure as long as RSA is deemed secure. Although there are no known attacks on PKSC#1 - besides the aforementioned padding oracle attack - the algorithm doesn't have a formal security proof so it is possible that attacks do exist.


These kind of things cannot be easily quantified. RSA has about no security if PKCS#1 padding oracles apply. The lack of security proof may lead to an attack in the future, but this is - very likely - independent of the key size. Neither calculations nor rules-of-thumb apply. You should rather take a good look at your use cases, threat-model and attack vectors.


Or just use OAEP. Many libraries support OAEP because PKCS#1 is deemed less secure. Using RSA-KEM would also be a good option if that's available to you (and it is relatively easy to create if you have raw RSA available).

$\endgroup$
6
  • 1
    $\begingroup$ Panacea = universal remedy that fixes all $\endgroup$
    – Maarten Bodewes
    May 15 '17 at 18:36
  • 6
    $\begingroup$ Or use RSA KEM and forget about all that padding crap. $\endgroup$ May 15 '17 at 21:50
  • $\begingroup$ It has proven to be a nightmare to guard against padding oracle attacks in RSAES-PKCS1-v1_5 (and that's not trivial for RSAES-OAEP). I have reviewed Bouncy Castle's implementation of that, and it's circles of break-and-improve+repair, with no insurance that there's no viable attack path for a clever adversary close enough (in particular, really close on the network, or worse on the same CPU), since that depends on minute details of the JVM+JIT. Thus if there's a choice, yes use RSA-KEM, or a good RSAES-OAEP, and try to avoid RSAES-PKCS1-v1_5. $\endgroup$
    – fgrieu
    Nov 27 '20 at 15:28
  • $\begingroup$ @fgrieu Yeah, I agree but there are two problems with it: RSA-KEM is not standardized by NIST it seems. Furthermore, there seem to be precious little implementations of it in the common cryptolibs... $\endgroup$
    – Maarten Bodewes
    Nov 27 '20 at 15:49
  • 1
    $\begingroup$ @Maarten Bodewes: yes, that's why I never actually used RSA-KEM, and use RSAES-OAEP. The other thing is that more often than not, one really needs to to encipher a particular key for a symmetric cipher, and RSA-KEM is not meant for that. $\endgroup$
    – fgrieu
    Nov 27 '20 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.