On Sun, 12 May 2024 18:10:33 GMT, Weijun Wang <wei...@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
