RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v7]
Sean Mullan
mullan at openjdk.org
Thu Sep 4 14:01:50 UTC 2025
On Thu, 4 Sep 2025 00:14:24 GMT, Valerie Peng <valeriep at openjdk.org> wrote:
>> This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods.
>>
>> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear.
>>
>> Thanks in advance for the review~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>
> Address review comments from Sean.
test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java line 85:
> 83:
> 84: checkTransformation("ChaCha20/ECB/NoPadding", Expected.NSAE_OR_NSPE);
> 85: checkTransformation("ChaCha20/None/PKCS5Padding", Expected.NSAE_OR_NSPE);
Isn't this always going to throw NSPE given the current provider configuration? Also, same comment on line 88.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2322282238
More information about the security-dev
mailing list