KDF API review, round 2
Michael StJohns
mstjohns at comcast.net
Mon Nov 20 20:34:41 UTC 2017
On 11/20/2017 1:10 PM, Jamil Nimeh wrote:
>
>> You're missing the point that setParameter() provides information
>> used in all future calls to the signature generation, while init()
>> provides data specifically for a given key stream production. In
>> Signature() you call .setParameter() to set up the PSS parameters (or
>> use the defaults). Each subsequent call to initSign or initVerify
>> uses those PSS parameters. The equivalent part of .init() in
>> KeyDerivation is actually the calls to .update() in signature as they
>> provide the specific information for the production of the output key
>> stream. In fact, setting up an HMAC signature instance and passing
>> it the mixin data as part of a .update() is a way of producing the
>> key stream round.
>>
>> So equivalences:
>>
>> KeyDerivation.getInstance(PRF) == Signature.getInstance(HMAC)
>> KeyDerivation.setParameters() == Signature.setParameters()
>> KeyDerivation.init(key, List<Parameters>) == concatenation of the
>> results of multiple calls (each key stream round based on the needed
>> output length) to [Signature.initSign(Key) followed by
>> Signature.update(converttobytearray(List<Parameters>)) followed by
>> Signature.sign()] to produce the key stream
>> KeyDerivation.deriveKey() == various calls to key or object
>> factories with parts of the key stream (signature).
>>
> Are you expecting that setParameters is called once per
> instantiation? If so, then the parameters that would go into
> setParameter (an APS I assume) could just as easily go into the
> getInstance call. It also removes the chance that someone would call
> it twice.
That was my original proposal. .setParameter() was an alternative that
matched the Signature pattern.
>
> If you're expecting someone to call setParameter more than once, then
> I would expect an init must follow. So why not place it in a form of
> init that allows you to change that particular set of params? Either
> way it seems like we could coalesce this method into one of the calls
> that sandwich it in your proposed model.
>
>
I don't expect them to call it more than once. The original (now
deprecated) .setParameter (String, Object) method in Signature indicated
it could be called only once and would throw an error if called again -
I'm not sure why that wasn't brought forward to the
Signature.setParameter(AlgorithmParameterSpec) method.
In any event, I'd rather do the parameter setting in the getInstance
call than as a separate .setParameters call if it can be done without
exploding the interface.
Hmm.. how does that map to the Spi? Does the
KeyDerivation.getInstance() code instantiate the object, call a
setParameter() method on the SPI and then return the new object? Or
what? It may make more sense to just add the parameter related methods
to both the KeyDerivationSpi and the KeyDerivation classes and leave the
getInstance() method alone....
I'm sort of a don't care as long as I have a way of tweaking the KDF
before run the first derivation.
Mike
More information about the security-dev
mailing list