New Draft of the KDF JEP for the Java Platform

[Martin Balao]

Hi Kevin,

When looking at the proposed API, I noticed that the length of a derived 
key or data can be potentially passed both as part of a KDFParameterSpec 
and as a KDF::deriveKey or KDF::deriveData parameter. This is the case 
for HKDF (HKDFParameterSpec) apparently. Having a length value on two 
places makes me think about all the possible combinations. By just 
reading the API, one cannot tell what could happen if values were 
different. It may be handled by the KDF class implementation or passed 
through to the SPI. One interpretation is that the length parameter (if 
valid) enforces a maximum to the output value in HKDFParameterSpec, and 
an error is thrown if the latter is smaller than the former. However, 
one of them could be invalid and that could lead to an error. Another 
interpretation would be that there is a check preventing these values to 
be different. I would like to hear your thoughts on this issue. Perhaps 
it is worth exploring a way to remove ambiguity or adding a note to the 
JEP. E.g. do we need to specify a len parameter or can we leave it for 
KDFParameterSpec to specify it and the key is built consuming all the 
output generated? Does it make sense to generate more output than what 
we are going to consume for a key? Looks like the extra output will be lost.

For some security providers, it may be interesting to keep state between 
KDF::deriveKey or KDF::deriveData calls in the HKDF algorithm, 
particularly during the expansion phase. For example, PKCS #11 providers 
will need the PRK as a key ID for the native C_DeriveKey call. If the 
HKDFParameterSpec forces the PRK to be a byte[], then each expansion 
call pays the cost of creating the key again in the token. This 
observation was made by @Francisco (on CC). Will the KDF class enforce 
the use of well-known KDFParameterSpec implementations such as 
HKDFParameterSpec or will it be open to each provider —e.g. 
engineGetParameters type of API—? In the latter case, will the call from 
JSSE be such that we can keep/carry state between extraction and expansion?

Thanks,
Martin.-


On 3/1/24 16:08, Kevin Driver wrote:
> Hi All,
> 
> As discussed a few months ago [1], we are working on providing a new API 
> for KDF (Key Derivation Functions). There will be a KDF class for users, 
> a KDFSpi class for security providers, and several other parameter 
> classes. We plan to add support for HKDF (RFC-5869).
> 
> For more details, see the updated draft JEP at: 
> https://openjdk.org/jeps/8189808 <https://openjdk.org/jeps/8189808>
> 
> As before, we look forward to your feedback on the proposal.
> 
> [1] 
> https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html 
> <https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html>
> 
> Thanks,
> 
> image001.png
> Kevin Driver
> Java Security Libraries
>