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

[Martin Balao]

On 3/13/24 08:52, Wei-Jun Wang wrote:
> 
>> On Mar 12, 2024, at 6:34 PM, Martin Balao <mbalao at redhat.com> wrote:
>>
>> 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.
> 
> For an extract-once expand-multiple use case, I think you can do an extract-only deriveKey and this returns the PRK. You can then use this PRK to do multiple expand-only deriveKeys. There is no need to store the PRK inside the params after the 1st step. Or, are you worrying about the PRK been leaked?

The extract phase gets the IKM from the HKDFParameterSpec and the 
derivation produces the PRK. My interpretation is that such PRK will be 
passed to the expansion phase in a HKDFParameterSpec to the next 
derivation call. All of this will be made from code that is agnostic of 
the provider. That's what I meant by passing state on the parameters 
side. If the IKM/PRK in HKDFParameterSpec is not a byte[] but a Key for 
example, that would work for SunPKCS11 because in the first extraction 
call the key is created in the token but in successive expansion calls 
the key (PRK) from the token is used, without needing to create it again 
over and over.