[External] : Re: New Draft of the KDF JEP for the Java Platform

[Martin Balao]

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 <mbalao at 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
>>
>