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
