On Thu, 29 Aug 2024 20:01:57 GMT, Kevin Driver wrote:
>> test/jdk/javax/crypto/KDF/KDFDelayedProviderSyncTest.java line 66:
>>
>>> 64: public void testDerive()
>>> 65: throws InvalidAlgorithmParameterException,
>>> NoSuchAlgorithmException {
>>> 66: SecretKey result = kdfUnd
On Wed, 28 Aug 2024 22:51:07 GMT, Valerie Peng wrote:
>> I double-checked, and the value was actually lengthened recently. Do you
>> have a value in mind?
>
> Maybe "100"? But I only tried this value a few times and observe no failures.
Addressed in
https://github.com/openjdk/jdk/pull/20301/co
On Thu, 29 Aug 2024 00:33:00 GMT, Weijun Wang wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> another round of review comments
>
> src/java.base/share/classes/javax/crypto/spec/HKDFParameterSpec.java line 287:
>
>
On Wed, 28 Aug 2024 22:47:14 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 476:
>>
>>> 474: * the object describing the inputs to the derivation function
>>> 475: *
>>> 476: * @return a {@code SecretKey} object corresponding to a key built
On Thu, 29 Aug 2024 18:50:26 GMT, Valerie Peng wrote:
>> Well, if a non-extractrable hardware key is passed to us, it'd lead to NPE
>> with the new check. Instead of calling getEncoded() on it and access length
>> directly, maybe relying on `CipherCore.getKeyBytes(prk)` which will throw
>> In
On Wed, 28 Aug 2024 23:51:38 GMT, Valerie Peng wrote:
>> Kevin Driver has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - consistency with wording for addIKM and addSalt
>> - another round of code review comments
>
> test/jdk/javax/crypto
> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic
> algorithms for deriving additional keys from a secret key and other data. See
> [JEP 478](https://openjdk.org/jeps/478).
>
> Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924).
Kevin Driver
On Mon, 26 Aug 2024 17:56:54 GMT, Weijun Wang wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> code review comments and test renaming
>
> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>
On Thu, 29 Aug 2024 18:57:59 GMT, Valerie Peng wrote:
>> Kevin Driver has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - consistency with wording for addIKM and addSalt
>> - another round of code review comments
>
> src/java.base/share/c
On Thu, 29 Aug 2024 16:38:52 GMT, Sibabrata Sahoo wrote:
>> Kevin Driver has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - consistency with wording for addIKM and addSalt
>> - another round of code review comments
>
> src/java.base/shar
On Thu, 1 Aug 2024 04:13:24 GMT, Anthony Scarpino wrote:
>> Hi all,
>>
>> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a
>> format for encoding and decoding cryptographic keys and certificates. It
>> will be integrated into JDK24 as a Preview Feature. Preview features
On Fri, 23 Aug 2024 21:44:44 GMT, Kevin Driver wrote:
>> These are "RAW" since the lengths are somewhat arbitrary in the KATs. It's
>> perhaps a bit misleading to create standard keys with strange output
>> lengths. Would you prefer "Generic" over "RAW"?
>
> Addressed in
> https://github.com/o
On Wed, 28 Aug 2024 20:44:10 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another P
On Wed, 21 Aug 2024 00:14:55 GMT, Valerie Peng wrote:
>> Addressed in
>> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
>> Please indicate if this is resolved.
>
> Well, if a non-extractrable hardware key is passed to us, it'd lead to NPE
> with the
On Wed, 28 Aug 2024 20:37:57 GMT, Kevin Driver wrote:
>> Every time HKDF-Expand is used in either TLS 1.3 or HPKE, there is always a
>> non-empty info. Even if the original RFC says this argument is optional, I
>> don't think it's useful to provide a one-argument overloaded method.
>
> Agreed.
On Thu, 29 Aug 2024 14:15:38 GMT, Weijun Wang wrote:
>> Resolved in
>> https://github.com/openjdk/jdk/pull/20301/commits/a65dc9da044297c313e02d698255bad915dc0a10.
>
> Personally I don't like the "mutate" word. But your sentence is quite
> complete now, so I don't have a strong opinion now.
`KD
On Thu, 29 Aug 2024 17:54:38 GMT, Kevin Driver wrote:
>> This is `KDF` not `KDFSpi`, the implementation is in this file. I just meant
>> this exception should be thrown when the condition described here is met.
>
> What do you propose? It's not clear how we would distinguish between NSAE and
>
On Mon, 26 Aug 2024 19:01:42 GMT, Weijun Wang wrote:
>> This is declared for implementation use. Are you arguing that no
>> implementation may require it?
>
> This is `KDF` not `KDFSpi`, the implementation is in this file. I just meant
> this exception should be thrown when the condition descri
On Thu, 29 Aug 2024 16:08:33 GMT, Kevin Driver wrote:
>> Sure, I added an if-check to skip the `hmacObj.update(...)` call for the i=0
>> case. This way, you don't need to set `tLength` to 0 and then changing it to
>> `hmacLen` afterwards. I find it easier to understand.
>
> But this way, the fi
On Mon, 26 Aug 2024 17:37:50 GMT, Weijun Wang wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> code review comments and test renaming
>
> src/java.base/share/classes/java/security/KDFParameters.java line 43:
>
>> 4
On Wed, 21 Aug 2024 00:09:25 GMT, Valerie Peng wrote:
>> Can someone help review this fix? Changed the required-mechanism check by
>> checking if the particular mechanism is inside the list of enabled supported
>> mechanisms. This should be more reliable than calling C_GetMechanismInfo(..)
>>
On Wed, 21 Aug 2024 00:09:25 GMT, Valerie Peng wrote:
>> Can someone help review this fix? Changed the required-mechanism check by
>> checking if the particular mechanism is inside the list of enabled supported
>> mechanisms. This should be more reliable than calling C_GetMechanismInfo(..)
>>
On Wed, 28 Aug 2024 20:44:10 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another P
On Wed, 21 Aug 2024 00:25:08 GMT, Valerie Peng wrote:
>> I'll need to double-check the logic of this snippet. For example, in the
>> first iteration of the loop, isn't `tLength` == 0? Yet, you have it always
>> set to `hmacLen`.
>
> Sure, I added an if-check to skip the `hmacObj.update(...)` ca
On Wed, 28 Aug 2024 20:37:04 GMT, Kevin Driver wrote:
>> OK, maybe you can just say the "actual" object. I still think `mutating` is
>> strange.
>
> Resolved in
> https://github.com/openjdk/jdk/pull/20301/commits/a65dc9da044297c313e02d698255bad915dc0a10.
Personally I don't like the "mutate" wo
On Wed, 28 Aug 2024 20:37:19 GMT, Kevin Driver wrote:
>> The way this is worded it is part of the API specification, so I would
>> expect `IllegalArgumentException` to be thrown if the length is less than
>> 255 * HMAC length. But as I understand, only the HKDF impl can do that. I
>> would ch
26 matches
Mail list logo
