RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v10]
Weijun Wang
weijun at openjdk.org
Wed Aug 7 16:35:40 UTC 2024
On Wed, 7 Aug 2024 00:25:09 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/4fcf73db...dd2ee48f
>
> src/java.base/share/classes/javax/crypto/KDFSpi.java line 65:
>
>> 63: * @param kdfParameters
>> 64: * the initialization parameters for the {@code KDF} algorithm (may be
>> 65: * {@code null})
>
> Should we further specify what {@code null} means or when it is (not-)allowed? For KDF algorithms which does not use initialization parameters, {@code null} should be specified, otherwise IAPE is thrown? However, for KDF algorithms which use initialization parameters, can {@code null} be specified? Is it ok for the provider to choose their own default values when {@code null} is specified through {@code KDF.getInstance()} calls? But then callers have to call {@code KDF.getKDFParameters()} to check/find out?
I would answer yes, yes, yes, yes, and YES. :-)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1707404257
More information about the security-dev
mailing list