Draft design for Key Derivation API

[Mike StJohns]

Hi - I on a plane tomorrow so it may be a few days before I can completely answer the email, but I wanted to hit this section.


Think of KeyDerivation as something that has a pattern similar to Cipher or KeyAgreement or Signature. The instantiation phase sets up the mechanism of the crypto object, but allows you to use that object with many keys through an init/reset (implicit or explicit) cycle.   That model works well with both software and hardware implementations.   In literally no case can I see it making sense to irrevocably bind the key to the keyderivation object and every reason not to do it.  Consider for a minute the server side of TLS.  Wouldn’t it make sense to instantiate a single KeyDerivation object and throw different master keys at it as they are negotiated?  Especially if the KeyDerivation object is an abstract for an HSM implementation.  

None of the other crypto main classes feed in the key during instantiation.  I don’t think it’s a good idea to vary the pattern without a better reason than you’ve given.  

more later -Mike



Sent from my iPad

> On Nov 7, 2017, at 17:17, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
> 
> One issue that came up on an early internal rev of the API was that we didn't want to separate instantiation and initialization, so all the inputs to the KDF now come in at getInstance time through AlgorithmParameterSpecs, rather than doing getInstance/init/... like KeyAgreement does.  I wonder if it would be OK to still have an init (and a reset as you wanted) method so we can provide new inputs top-to-bottom into the KDF object.  All the getInstance forms would stay more or less the same, so there's no way to make a KDF object without it being in an initialized state.  But when you need new inputs you don't have to make a new object.  I like being able to reuse the object and reset it to its starting state.  I don't know if the folks that brought up the instance/init issue would have a problem with that.  I think we're still adhering to the spirit of what they wanted to see since getInstance still gives you a fully initialized object.