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

Kevin Driver kdriver at openjdk.org
Fri Aug 30 23:15:49 UTC 2024


On Fri, 9 Aug 2024 01:59:46 GMT, Anthony Scarpino <ascarpino 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/48952c86...dd2ee48f
>
> src/java.base/share/classes/javax/crypto/KDF.java line 121:
> 
>> 119:     private Iterator<Service> serviceIterator;
>> 120: 
>> 121:     private final Object lock;
> 
> Why are you using an `Object` as a lock instead of something like `ReentrantLock`?  I realize older implementations used this style, but does this need to be mimicked?

@valeriepeng:

I did some research. Based upon what I have seen, no `volatile` keyword is required here. This is also consistent with the `Cipher` API, for example.

@ascarpino: 

I looked up `ReentrantLock`s, and I’m not sure those make sense for the use-case. A simple mutex lock should suffice, since we will not be spinning for long. In addition, as mentioned above, we are consistent with the other JCE/JCA classes by using this paradigm.

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

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


More information about the security-dev mailing list