KDF API review, round 2

[Jamil Nimeh]

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 K_I , 
and K_I 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
_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171127/d8d73ab1/attachment.htm>