On Fri, 16 Aug 2024 01:15:30 GMT, Valerie Peng <valer...@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
