KDF API review, round 2

Michael StJohns mstjohns at comcast.net
Mon Nov 27 19:46:40 UTC 2017


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.

Thanks - Mike






More information about the security-dev mailing list