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

Kevin Driver kdriver at openjdk.org
Thu Aug 15 21:09:01 UTC 2024


On Thu, 15 Aug 2024 20:12:09 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 124:
> 
>> 122:         List<SecretKey> salts;
>> 123:         SecretKey inputKeyMaterial;
>> 124:         SecretKey salt;
> 
> Looking at the implementation, it seems you can just use byte[] for `inputKeyMaterial` and `salt`. Why bother packaging the bytes into a `SecretKey` object and later calling `getEncoded()` to retrieve it again?

We use SecretKey, because sometimes the raw bytes may not be available to us, for example if it's a hardware key.

> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java line 151:
> 
>> 149:             try {
>> 150:                 return hkdfExtract(inputKeyMaterial,
>> 151:                                    (salt == null) ? null : salt.getEncoded());
> 
> If you use byte[] for `salt`, then you can just pass it to `hkdfExtract()` and no need for this null-check and `getEncoded()` call.

See above comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1718993177
PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1718993640



More information about the security-dev mailing list