Hi Martin. To be brief, we will be removing the length parameter from the deriveKey arguments list. There was some thought that there may be a use-case where the caller would not want to use all the generated entropy, but at this time, we have no valid use-case for this in the current API design.
This version of the API reflects our intention for a stateless API design (or put another way, that the “deriveKey/deriveData” calls are one-and-done operations). As for the PKCS#11 questions you pose: 1) The PRK is not required to be a byte[]. We have considered the PKCS#11 case, and the caller will not need to re-derive the PRK each time. 2) Furthermore, state does not need to be maintained between calls to the deriveKey/deriveData methods, since the parameters from an extract (including the PRK) can be passed to any successive expand calls. Perhaps it will be helpful/demonstrative for us to include some finer details about the HKDFParameterSpec class in the JEP write-up. More soon. Thanks! [image001.png] Kevin Driver Mobile: +1.512.431.5690 Java Security Libraries On Mar 12, 2024, at 4:25 PM, Martin Balao <mba...@redhat.com> wrote: 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
