Hi Kevin,
Thanks for your quick response.
On 3/12/24 17:52, Kevin Driver wrote:
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.
Makes sense.
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.
As I understand it, it's not that state is not maintained but that we
are keeping it on the parameters side. For example, a extraction phase
call will generate a PRK that will be kept in the parameters side for
the following expansion phase calls.
Perhaps it will be helpful/demonstrative for us to include some finer
details about the HKDFParameterSpec class in the JEP write-up.
That would be appreciated, as we are exploring a SunPKCS11
implementation —I am not sure if you got the chance to see my email on
that regard—.
Thanks,
Martin.-
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
