KDF API review, round 2

[Weijun Wang]

Very very new to this discussion. If what I say below does not make sense, please ignore it.

I'm still finding it uncomfortable to provide _n_ DPSes in initialize() and let user to call deriveKey() _n_ times later. (Or, is this still the preferred way?) If providing all DPSes up-front helps an HSM to emit all keys in a single operation (this is how I understand the reason), do you expect user calling deriveKeys() to get all of them or calling deriveKey() again and again? If the former, we can still put DPS into deriveKey (i.e. deriveKey(DPS) and deriveKeys(DPS[])) and restrict that deriveKey(s) can only be called once with each initialize() so they are not "abused".

If user uses this a PRNG, they can always call deriveData() indefinitely.

Thanks
Max

> On Nov 28, 2017, at 6:23 AM, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
> 
> 
> 
> On 11/27/2017 11:46 AM, Michael StJohns wrote:
>> On 11/27/2017 2:16 PM, Jamil Nimeh wrote: 
>>> See above with respect to set/getParameter.  But hopefully you'll be happy with the API after this next round.  I have one other change I will be making.  I'm removing deriveObject.  I'm uncomfortable right now with the idea of the API executing an arbitrary class' constructor.  This is something I'm definitely willing to examine in the future once the most pressing tasks both with this API, and projects that are immediately depending on it are take care of. It is easier to add calls to the API than it is to remove/modify/deprecate them if there's a problem.  I will file an RFE so that we can track this enhancement. 
>>> 
>>> Modifications to the KeyAgreement API are beyond the scope of this JEP.  We can certainly discuss ideas you have, but this KDF JEP isn't going to be dependent on those discussions. 
>> 
>> 
>> Fair enough. 
>> 
>> The deriveObject stuff is a problem because it doesn't fit well in the JCA.  Mostly we've got KeyGenerator/KeyPairGenerator/KeyFactory that produce objects of a particular provider.  KeyDerivation is weird in that one provider will be producing the derived key stream and potentially others might need to provide key or cryptographic objects from that stream.   I can see the point in delaying this to a later rev though it might make something like [KDF is Bouncycastle, keys are PKCS11] a bit difficult to work around. 
>> 
>> Last one - 
>> 
>> Can I get you to buy into a MasterKey/MasterKeySpec  that is not a sub class of SecretKey but has the same characteristics (and probably the same definitions) as those classes (and is what gets used in the .init() argument)?  This goes back to trying to prevent a SecretKey from being used both with a KDF and the underlying PRF of the KDF.  I know this is a don't care for software based providers but would be useful for security module based ones. 
>> 
>> I'm really hoping to improve cryptographic type and use safety along the way. 
> 
> I'm not quite getting what you mean here.  From looking at KDFs described in 800-108, it looks like the key input to the KDF is KI, and KI ends up being the seed for each round of the PRF.  If that isn't what you're referring to can you explain what you're looking for in more detail?
> 
> --Jamil