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

Sean Mullan mullan at openjdk.org
Tue May 14 21:51:46 UTC 2024


On Sun, 12 May 2024 18:10:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KDF.java line 414:
>> 
>>> 412:      *
>>> 413:      */
>>> 414:     public SecretKey deriveKey(String alg, KDFParameterSpec kdfParameterSpec)
>> 
>> Are there cases where the parameters are correct, but the derive operation can still fail for other reasons? If so, I'm not sure we should be wrapping those in InvalidParameterSpecException. That exception should be thrown by the method initially when it inspects the parameters and before the derive operation begins.
>> 
>> This is why I mentioned previously if it makes sense to add a DerivationException class.
>
> First, very wrong parameters (say, null info, negative length) should not be create-able at all.
> 
> Then, in some cases, "correct" parameters could still be "invalid". For example, HKDF expand key length cannot exceed HashLen * 255, but HashLen is determined by the KDF algorithm. In this case, maybe an `InvalidAlgorithmParameterException` should be thrown because it does not conform to the spec.
> 
> Sometimes the implementation just does not support some parameters. For example, in PKCS #11 you cannot provide an arbitrary string as the algorithm name. Also, only if HKDF expand "info" is a well-known value that's recognized by the underlying implementation, `deriveData` is able to return a byte array. See 7a in https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.1/os/pkcs11-profiles-v3.1-os.html#_Toc142307348. In these cases, maybe an `UnsupportedOperationException` should be thrown because the implementation does not support them.

Let's leave it as is for now, but make a note to revisit this later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1600667346



More information about the security-dev mailing list