On 11/17/2017 10:10 AM, Michael StJohns wrote:
On 11/16/2017 1:29 PM, Adam Petcher wrote:
On 11/8/2017 6:50 PM, Michael StJohns wrote:
What is the motivation behind this constructor that takes a byte
array? It seems like this constructor wouldn't actually help in a
hardware implementation. Would it be better to leave the construction
of this object to the implementation?
This is a reasonable point, but misses a few things. If you're
calling the hardware implementation from software, you need to be able
to pass data from the software domain to hardware domain. If the KDF
and the Object are both in hardware, then the provider implementation
doesn't actually externalize the byte array from the KDF - it just
returns the final pointer to the object.
The hardware/software boundary has some unique challenges - mostly
these are handled OK in the JCA. For this particular model, you need
to be able to move bits from software to hardware which is the point
of the constructor as specified. For hardware to hardware it happens
under the hood. For hardware to software it may be prohibited (e.g.
you can't actually externalize the bits of the key stream), but if its
permitted then you need a simple way of translating key stream bytes
into an object.
That behavior all sounds reasonable, I just have doubts that this
belongs in the spec. Are you expecting KeyDerivation to contain the
logic in your last paragraph? Something like this:
class KeyDerivation{
Object deriveObject() {
try {
return spi.deriveObject();
} catch (...) {
Class clazz = // get the class from the parameters
return clazz.newInstance(deriveData(), length); // shorthand for
getting the right ctor and calling it
}
}
}
I would expect something like that to happen in the KeyDerivationSpi
implementation instead, in which case it could construct the object any
way it wants. So the spec would not need to place any requirements on
the class of objects returned by deriveObject.
