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
