RFR: 8273977: Reduce unnecessary BadPaddingExceptions in RSAPadding

[Lari Hotari]

On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari <duke at openjdk.java.net> wrote:

> ### Motivation
> 
> When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code in RSAPadding, one can see that BadPaddingException is created in all cases, also on the success path:
> https://github.com/openjdk/jdk/blob/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L369-L375
> 
> ### Modifications
> 
> Inline the unnecessary local variable to prevent creating the exception on the success path.

In Twitter, it was brought up to attention that "PKCS v1.5 is vulnerable to Bleichenbacher if the check is not constant-time, but there's no reason to leave it in the OAEP (second) function." , https://twitter.com/typish_cast/status/1439875435953786881 .

For unpadV15 method one possible option to retain the "constant-time property of the code" would be to use a stackless exception (by overriding fillInStackTrace) that is an immutable / constant & singleton instance? That wouldn't cause a performance hit for the success path.

For anyone interested, there's an explanation of the [Bleichenbacher's CCA attack on PKCS#1 v1.5 on Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5). The original paper is ["Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" ](http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf).

The reason for constant time is to not leak information about a possible bad padding to the attacker based on the difference in response time between a valid and bad padding. The attacker can use this information to narrow the search to find the pre-master secret.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5581