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

[Kevin Driver]

On Sat, 3 Aug 2024 00:43:20 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - update test to include Spi updates
>>  - Update with latest from master
>>    
>>    Merge remote-tracking branch 'origin/master' into kdf-jep-wip
>>    # Please enter a commit message to explain why this merge is necessary,
>>    # especially if it merges an updated upstream into a topic branch.
>>    #
>>    # Lines starting with '#' will be ignored, and an empty message aborts
>>    # the commit.
>>  - add engineGetKDFParameters to the KDFSpi
>>  - code review comment fix for javadoc specification
>>  - change course on null return values from derive methods
>>  - code review comments
>>  - threading refactor + code review comments
>>  - review comments
>>  - review comments
>>  - update code snippet type in KDF
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/7c6c6041...dd2ee48f
>
> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 468:
> 
>> 466:                 "com.sun.crypto.provider.HkdfKeyDerivation$HkdfSHA384");
>> 467:         ps("KDF", "HKDFWithHmacSHA512",
>> 468:                 "com.sun.crypto.provider.HkdfKeyDerivation$HkdfSHA512");
> 
> Have you considered names such as HKDFWithSHA256? The "Hmac" part is sort of implied by the HKDF (Hmac-based Key Derivation Function). This also better matches the names used in [RFC 8619](https://datatracker.ietf.org/doc/html/rfc8619 ) which defines OIDs for HKDF. Now that we are adding support for HKDF, maybe add these oids to KnownOIDs?

@valeriepeng: @seanjmullan: @wangweij: There are `Cipher`s with this convention, namely: `PBEWithHmacSHA512/256AndAES_256` and many others. In addition, there are corresponding `AlgorithmParameters` and `SecretKeyFactory` declarations.

I am not opposed to adopting the proposed convention -- just offering an alternate view. 

Replied with this same comment in another place where @valeriepeng mentioned this issue.

> src/java.base/share/classes/javax/crypto/KDFSpi.java line 89:
> 
>> 87:      * @throws UnsupportedOperationException if this method is not overridden
>> 88:      * by a provider
>> 89:      */
> 
> The method is abstract meaning this method must be overridden?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1715419547
PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1715423565