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

[Kevin Driver]

On Fri, 16 Aug 2024 01:15:30 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed several review comments, namely: - renaming the getParameters method - renaming the AlgorithmParameterSpec object - address some javadoc exception messages - add some information to KDF class private constructor javadocs - other general cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java line 227:
> 
>> 225:                                                                       == null) ? null : salt.getEncoded());
>> 226:                 pseudoRandomKey = new SecretKeySpec(extractResult, "RAW");
>> 227:                 return Arrays.copyOf(hkdfExpand(pseudoRandomKey, info, length),
> 
> In the case of `length` is an exact multiples of hmac out length, we can return the output directly w/o the `Arrays.copyOf(...)` call, right?

See: https://github.com/openjdk/jdk/pull/20301/commits/25c17b26231b2b63bab9193fe29c7c258f96a31f

> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java line 256:
> 
>> 254:                 // return this element
>> 255:                 SecretKey checkIt = localKeys.get(0);
>> 256:                 byte[] workItemBytes = CipherCore.getKeyBytes(checkIt);
> 
> As my other comments suggested, you could have just returned `workItemBytes` directly here and the concatenated bytes for the other case. No need to package them into a `SecretKey` object. Hardware keys are rejected by the `CipherCore.getKeyBytes()` with an InvalidKeyException already.

See: https://github.com/openjdk/jdk/pull/20301/commits/25c17b26231b2b63bab9193fe29c7c258f96a31f

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1739512170
PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1739512139