RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v43]

[Kevin Driver]

On Wed, 18 Sep 2024 21:47:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refinement of addIKM and addSalt specifications
>
> src/java.base/share/classes/com/sun/crypto/provider/HKDFKeyDerivation.java line 66:
> 
>> 64:             SHA384_HMAC_SIZE,
>> 65:             SHA512_HMAC_SIZE
>> 66:     };
> 
> These lines can be removed if using enum to group the name and output length together. The current check does very little, it only ensures that the specified hmac length is one of the supported values, but no correlation with the hmac algorithm name. The enum sample code is shown in a separate comment below.

Addressed in https://github.com/openjdk/jdk/pull/20301/commits/f786a38179651a5bca8c4884eeb52d2cef0adc78.

> src/java.base/share/classes/javax/crypto/KDF.java line 405:
> 
>> 403: 
>> 404:         } catch (NoSuchAlgorithmException nsae) {
>> 405:             return handleException(nsae);
> 
> Is there really scenario requiring `handleException()`? I mean, is there really `NoSuchAlgorithmException` object containing `InvalidAlgorithmParameterException` as cause and need to be thrown as  `InvalidAlgorithmParameterException`? Can you show a possible call path for this to happen?
> Same goes for the other `handleException()` call on line 457.

This is to surface wrapped `IAPE`s. I'll have to do some digging to see whether this is still possible after the recent DPS refactoring; however, it was possible at one point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1769194296
PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1769196459