On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari <d...@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
