On Fri, 6 Sep 2024 14:06:08 GMT, Viktor Klang wrote:
>> My understanding is that `volatile` is used when accessing the contents of
>> the object, which we are not doing with this locking object, so IMO there is
>> no reason for the keyword to be added.
>>
>> I'll apply your other suggestion ab
On Fri, 6 Sep 2024 14:06:08 GMT, Viktor Klang wrote:
>> My understanding is that `volatile` is used when accessing the contents of
>> the object, which we are not doing with this locking object, so IMO there is
>> no reason for the keyword to be added.
>>
>> I'll apply your other suggestion ab
On Thu, 5 Sep 2024 17:50:19 GMT, Kevin Driver wrote:
>> I'd recommend documenting above this line what function the lock is
>> intending to serve, and by each of the members that it guards accesses to.
>> Something like "//guarded by 'lock'".
>>
>> Also, ook into whether the members guarded by
On Thu, 5 Sep 2024 15:50:42 GMT, Viktor Klang wrote:
>> Well, I am not so sure, I've sent you pointers separately regarding lazy
>> initialization and the relevant concurrency pointers.
>
> I'd recommend documenting above this line what function the lock is intending
> to serve, and by each of
On Tue, 3 Sep 2024 20:16:23 GMT, Valerie Peng wrote:
>> @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 n
On Fri, 16 Aug 2024 18:25:19 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 144:
>>
>>> 142: salt = consolidateKeyMaterial(salts);
>>> 143: } catch (InvalidKeyException ike) {
>>> 144: th
On Fri, 30 Aug 2024 23:13:04 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 121:
>>
>>> 119: private Iterator serviceIterator;
>>> 120:
>>> 121: private final Object lock;
>>
>> Why are you using an `Object` as a lock instead of something like
>> `R
On Fri, 9 Aug 2024 01:59:46 GMT, Anthony Scarpino 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
>> commit
On Fri, 16 Aug 2024 21:06:51 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 441:
>>
>>> 439: }
>>> 440:
>>> 441: private static KDF handleException(NoSuchAlgorithmException e)
>>
>> My comment originates more with the callers of this method. While I
On Tue, 13 Aug 2024 14:39:58 GMT, Kevin Driver wrote:
>> 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:
On Wed, 14 Aug 2024 15:29:21 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDFSpi.java line 72:
>>
>>> 70: */
>>> 71: protected KDFSpi(KDFParameters kdfParameters)
>>> 72: throws InvalidAlgorithmParameterException {}
>>
>> The implementation doesn't do an
On Mon, 26 Aug 2024 16:20:31 GMT, Sean Mullan wrote:
>> Addressed in
>> https://github.com/openjdk/jdk/pull/20301/commits/48395b86ba8e1cda663ae326e06ae2556f4b905a.
>> Please indicate if this is resolved.
>
> I think "cannot be null" or "must not be null" is more precise and
> unambiguous. The
On Tue, 13 Aug 2024 15:19:30 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 458:
>>
>>> 456: * @param alg
>>> 457: * the algorithm of the resultant {@code SecretKey} object
>>> 458: * @param kdfParameterSpec
>>
>> I think this parameter sho
On Fri, 16 Aug 2024 21:04:02 GMT, Kevin Driver wrote:
>> Ignore my suggestion. I'm convinced now that unless specified we should
>> consider the return value non nullable. Sorry.
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
> Pl
On Fri, 16 Aug 2024 21:04:22 GMT, Kevin Driver wrote:
>> Well, I am not too sure if we should state it this way as we have no way to
>> tell if the KDF parameters are valid or not since KDF class is not coded
>> with algorithm-specific knowledge to validate it. How about we just simply
>> stat
On Mon, 19 Aug 2024 21:37:29 GMT, Kevin Driver wrote:
>> How about the "may" => "should" change?
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/48395b86ba8e1cda663ae326e06ae2556f4b905a.
> Please indicate if this is resolved.
I think "cannot be null" or "must not be null"
On Fri, 16 Aug 2024 23:35:47 GMT, Valerie Peng wrote:
>> Addressed in
>> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
>> Please indicate if this is resolved.
>
> Yes.
> However I still question the current naming convention of using HmacXXX with
>
On Fri, 16 Aug 2024 21:04:36 GMT, Kevin Driver wrote:
>> I would answer yes, yes, yes, yes, and YES. :-)
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
> Please indicate if this is resolved.
Yes, resolved.
-
PR Revie
On Fri, 16 Aug 2024 21:07:17 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 245:
>>
>>> 243: }
>>> 244:
>>> 245: private static boolean isNullOrEmpty(Collection c) {
>>
>> This appears to not be used.
>
> Addressed in
>
On Fri, 16 Aug 2024 21:05:48 GMT, Kevin Driver wrote:
>> +1, clearer to just state "xxx does not use configuration parameters" or
>> something similar where xxx is the HKDF algorithm name.
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4
On Fri, 16 Aug 2024 21:05:32 GMT, Kevin Driver wrote:
>> Like the above method, I suggested "KDFParameters must be specified." I'm
>> fine if you choose Valerie's suggestion
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
> Pleas
On Fri, 16 Aug 2024 23:38:56 GMT, Valerie Peng wrote:
>> Addressed in
>> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab42b29e4055.
>> Please indicate if this is resolved.
>
> How about the "may" => "should" change?
Addressed in
https://github.com/openjdk/jdk/
On Fri, 16 Aug 2024 18:18:51 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 258:
>>
>>> 256: byte[] workItemBytes = CipherCore.getKeyBytes(checkIt);
>>> 257: return new SecretKeySpec(workItemBytes, "
On Fri, 16 Aug 2024 21:05:23 GMT, Kevin Driver wrote:
>> Why do the null check on {@code provider} here? For consistency sake, since
>> both {@code algorithm} and {@code provider} are checked for non-null inside
>> {@code getInstance(String, KDFParameters, String), you should either check
>> b
On Fri, 16 Aug 2024 21:05:06 GMT, Kevin Driver wrote:
>> Yes, I am aware of the Cipher transformations, etc. It's just that the
>> sentence seems to imply the naming convention is from RFC 5869.
>
> Addressed in
> https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e6431b2ba9d4ab4
On Wed, 14 Aug 2024 16:47:38 GMT, Valerie Peng wrote:
>> The text implies that implementations may throw
>> `UnsupportedOperationException` in their method body, even though they are
>> technically forced to override the method.
>
> Well, I'd strongly suggest changing the text to something like
On Wed, 7 Aug 2024 16:32:50 GMT, Weijun Wang wrote:
>> 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 w
On Fri, 16 Aug 2024 18:46:39 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 479:
>>
>>> 477: throws InvalidAlgorithmParameterException {
>>> 478:
>>> 479: if (alg == null || alg.isEmpty()) {
>>
>> Well, should NPE be thrown for empty stri
On Tue, 13 Aug 2024 19:37:09 GMT, Weijun Wang wrote:
>> @seanjmullan: This text was added here at @wangweij's request, since he felt
>> that it should be explicitly stated that null cannot be returned.
>
> Ignore my suggestion. I'm convinced now that unless specified we should
> consider the re
On Mon, 12 Aug 2024 20:53:36 GMT, Anthony Scarpino
wrote:
>> Same goes for line 291-292.
>
> Like the above method, I suggested "KDFParameters must be specified." I'm
> fine if you choose Valerie's suggestion
Addressed in
https://github.com/openjdk/jdk/pull/20301/commits/c6f491cd05c76088e64
On Tue, 13 Aug 2024 18:22:22 GMT, Valerie Peng wrote:
>> @seanjmullan: Addressed in
>> https://github.com/openjdk/jdk/pull/20301/commits/59a3f02015f7fc3ad81ca29b90d83b1c9bd70fc5.
>> Please resolve this conversation if satisfied.
>
> Well, I am not too sure if we should state it this way as we h
On Thu, 8 Aug 2024 19:30:31 GMT, Valerie Peng 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 si
On Tue, 13 Aug 2024 21:26:11 GMT, Valerie Peng wrote:
>> @valeriepeng: There are `Cipher`s with this convention, namely:
>> `PBEWithHmacSHA512/256AndAES_256` and many others. In addition, there are
>> corresponding `AlgorithmParameters` and `SecretKeyFactory` declarations.
>
> Yes, I am aware o
On Thu, 8 Aug 2024 19:29:41 GMT, Valerie Peng wrote:
>> Same goes for other {@code Object.requireNonNull()} calls
>
> Why do the null check on {@code provider} here? For consistency sake, since
> both {@code algorithm} and {@code provider} are checked for non-null inside
> {@code getInstance(St
On Mon, 12 Aug 2024 23:33:42 GMT, Anthony Scarpino
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
>> comm
On Wed, 14 Aug 2024 02:28:52 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 74:
>>
>>> 72: if (kdfParameters != null) {
>>> 73: throw new InvalidAlgorithmParameterException(
>>> 74: "RFC 5869 has
On Tue, 13 Aug 2024 18:24:58 GMT, Valerie Peng 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 s
On Mon, 12 Aug 2024 23:12:55 GMT, Anthony Scarpino
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
>> comm
On Tue, 13 Aug 2024 00:13:38 GMT, Anthony Scarpino
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
>> comm
On Wed, 14 Aug 2024 15:30:48 GMT, Kevin Driver wrote:
>> Since it must be overridden, no way for the `UnsupportedOperationException`
>> to happen?
>
> The text implies that implementations may throw
> `UnsupportedOperationException` in their method body, even though they are
> technically forc
On Wed, 7 Aug 2024 01:06:52 GMT, Valerie Peng 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 si
On Tue, 13 Aug 2024 21:51:55 GMT, Valerie Peng wrote:
>> Yes. We want the implementation to return the parameters, especially if it
>> is supplying any defaults.
>
> Since it must be overridden, no way for the `UnsupportedOperationException`
> to happen?
The text implies that implementations m
On Fri, 9 Aug 2024 01:40:51 GMT, Anthony Scarpino 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
>> commit
On Tue, 13 Aug 2024 14:42:23 GMT, Kevin Driver wrote:
>> 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
On Tue, 13 Aug 2024 21:42:39 GMT, Valerie Peng wrote:
>> @valeriepeng: Addressed in
>> https://github.com/openjdk/jdk/pull/20301/commits/59a3f02015f7fc3ad81ca29b90d83b1c9bd70fc5.
>> Please resolve this conversation if satisfied.
>
> Ok~
I don't see the resolve this conversation setting though.
On Tue, 13 Aug 2024 15:21:16 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 149:
>>
>>> 147: }
>>> 148:
>>> 149: private KDF(Service s, Iterator t, String algorithm,
>>
>> nit: add comment that this constructor is used when no provider is supplied.
>
On Tue, 13 Aug 2024 14:31:59 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 52:
>>
>>> 50: * of methods. For https://www.rfc-editor.org/rfc/rfc5869";>RFC
>>> 5869,
>>> 51: * KDF algorithm names follow a naming convention of
>>> 52: * AlgorithmWithPRF. For
On Tue, 13 Aug 2024 14:23:12 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 465:
>>
>>> 463: * permitting a {@code null} return value here,
>>> implementations will
>>> 464: * handle cases where a value cannot be returned by throwing an
>>>
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Tue, 13 Aug 2024 15:20:13 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 413:
>>
>>> 411: * algorithm
>>> 412: * @throws InvalidAlgorithmParameterException
>>> 413: * if the {@code KDFParameters} is an invalid value
>>
>> I don't thi
On Wed, 7 Aug 2024 23:50:16 GMT, Valerie Peng 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 si
On Mon, 5 Aug 2024 20:04:35 GMT, Sean Mullan 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 sin
On Sat, 3 Aug 2024 00:43:20 GMT, Valerie Peng 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 si
On Wed, 7 Aug 2024 21:37:23 GMT, Valerie Peng 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 si
On Mon, 5 Aug 2024 17:36:36 GMT, Sean Mullan 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 sin
On Thu, 8 Aug 2024 01:51:51 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 259:
>>
>>> 257: throw new NoSuchAlgorithmException(
>>> 258: "Received an InvalidAlgorithmParameterException. Does
>>> this "
>>> 259: + "a
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Thu, 8 Aug 2024 01:48:27 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 253:
>>
>>> 251: public static KDF getInstance(String algorithm, String provider)
>>> 252: throws NoSuchAlgorithmException, NoSuchProviderException {
>>> 253: Object
On Thu, 8 Aug 2024 01:47:07 GMT, Valerie Peng 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 si
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Wed, 7 Aug 2024 00:25:09 GMT, Valerie Peng 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 si
On Wed, 7 Aug 2024 15:06:19 GMT, Sean Mullan wrote:
>> 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:
>>
On Sat, 3 Aug 2024 00:43:20 GMT, Valerie Peng 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 si
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Fri, 2 Aug 2024 19:19:54 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 PR
On Thu, 1 Aug 2024 22:29:21 GMT, Weijun Wang wrote:
>> I disagree. I think this is a helpful bit of info for the developer who may
>> be surprised later by an `Exception`.
>
> OK. As long as the exception does not cover it.
You should be careful putting the word "must" in an API specification -
On Fri, 2 Aug 2024 19:19:54 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 PR
On Thu, 1 Aug 2024 21:05:08 GMT, Weijun Wang wrote:
>> I was trying to convey that deriveKey|Data are not like doFinal in that they
>> can be called more than once on a single instance. Is there a different way
>> to word this? Or is it not important to mention here?
>
> Not sure. Maybe your se
On Fri, 2 Aug 2024 19:19:54 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 PR
On Wed, 31 Jul 2024 19:26:09 GMT, Weijun Wang 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 si
On Wed, 31 Jul 2024 19:28:33 GMT, Weijun Wang 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 si
On Wed, 31 Jul 2024 21:07:49 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/KDF.java line 51:
>>
>>> 49: *
>>> 50: * {@code KDF} objects are instantiated with the {@code getInstance}
>>> family of
>>> 51: * methods. KDF algorithm names follow a naming convention of
>>
On Fri, 2 Aug 2024 19:16:59 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 PR
On Thu, 1 Aug 2024 20:47:21 GMT, Weijun Wang wrote:
>> The existing sentence seems to cover this scenario. Let me know if you
>> disagree.
>>
>> `In some cases the WithPRF portion of the algorithm field may be omitted if
>> the KDF algorithm has a fixed or default PRF.`
>>
>> However, if Arg
> 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
82 matches
Mail list logo
