RFR: 8302017: Allocate BadPaddingException only if it will be thrown

[Ahmed Muhsin]

On Sat, 25 Feb 2023 02:38:47 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
>> 
>> The build and tier1 tests pass locally on mac-aarch64.
>
> src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 370:
> 
>> 368: 
>> 369:         if (bp) {
>> 370:             throw new BadPaddingException("Decryption error");
> 
> I assume the reason it was originally written this way was to ensure both the successful and unsuccessful paths are constant time to avoid timing attacks here, see the comment on method.
> 
> I am not a cryptographer but I'm wondering if you could use a preallocated `BadPaddingException` and/or overriding `fillInStackTrace() { return this; }` 
> 
> https://github.com/openjdk/jdk/blob/caef0a589cb31e97e0ef9e8355d4aa3325908140/src/java.base/share/classes/sun/security/rsa/RSAPadding.java#L331-L333

@schlosna you are right, that is the reason that it was originally written that way. However, based on the comments made by @djelinski and @bradfordwetmore in the [JBS work item](https://bugs.openjdk.org/browse/JDK-8302017),  that wasn't needed to meet the mandates set by [RFC 8017](https://www.rfc-editor.org/rfc/rfc8017). In particular:

Note: Care must be taken to ensure that an opponent cannot
      distinguish the different error conditions in Step 3.g, whether by
      error message or timing, and, more generally, that an opponent
      cannot learn partial information about the encoded message EM.
      Otherwise, an opponent may be able to obtain useful information
      about the decryption of the ciphertext C, leading to a chosen-
      ciphertext attack such as the one observed by Manger [[MANGER](https://www.rfc-editor.org/rfc/rfc8017#ref-MANGER)].

Which only requires that the different error cases be indistinguishable. Success cases are allowed to be distinguishable from failures though.

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

PR: https://git.openjdk.org/jdk/pull/12732