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

[Weijun Wang]

On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver <kdriver at openjdk.org> 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).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc formatting

We cannot say the KDF instance is immutable because it does have an internal state and it could change. On the other hand, because 1) the change is done only once, 2) it's synchronized, 3) it's not observable before the change, we can at least say the instance is "stable", which means its `getProviderName` method will always return the same value. It's a little unfortunate that even the `getProviderName` performs a provider selection, but this is all for the "stable" effort. If it throws an ISE, then the object's mutability is publicly observable. We've done this in all existing crypto engines, like `Signature`, `KeyAgreement`, and `Cipher`. I don't think it's worth introducing a brand new behavior.

As for the benefit of this design in a real world environment, I think it's safe to assume that an application usually has input keying materials of the same type, either software based or from an HSM, and in this case the correct provider will be selected and all `deriveXyz` calls should succeed. On the other hand, if multiple threads call the method with different types of input keying materials, then yes some will succeed and some will fail, and it depends on who is the 1st one to acquire the lock to decide the provider. This could also happen in a single thread. I don't think this can be called intermittent, either this half or the other half will fail anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/18924#issuecomment-2115083687