KDF API review, round 2
Adam Petcher
adam.petcher at oracle.com
Fri Nov 17 18:07:05 UTC 2017
On 11/17/2017 10:04 AM, Michael StJohns wrote:
> On 11/16/2017 2:15 PM, Adam Petcher wrote:
>> So it seems like they could all be supplied to init. Alternatively,
>> algorithm names could specify more concrete algorithms that include
>> the mode/PRF/etc. Can you provide more information to explain why
>> these existing patterns won't work in this case?
> What I need to do is provide a lifecycle diagram, but its hard to do
> in text. But basically, the .getInstance() followed by
> .setParameters() builds a concrete engine while the .init()
> initializes that engine with a key and the derivation parameters.
> Think about a TLS 1.2 instance - the PRF is selected once, but the KDF
> may be used multiple times.
This is the information I was missing. There are two sets of parameters,
and the first set should be fixed, but the second set should be changed
on each init.
>
> I considered the mode/PRF/etc stuff but that works for things like
> Cipher and Signature because most of those have exactly the same
> pattern. For the KDF pattern we;ve got fully specified KDFs (e.g. TLS
> 1.1 and before, IPSEC), almost fully specified KDFs (TLS 1.2 and HDKF
> needs a PRF) and then the SP800 style KDFs which are defined to be
> *very* flexible. So translating that into a naming convention is
> going to be restrictive and may not cover all of the possible
> approaches. I'd rather do it as an algorithmparameter instead. With
> a given KDF implementation having a default if nothing is specified
> during instantiation.
I agree that this is challenging because there is so much variety in
KDFs. But I don't think that SP 800-108 is a good example of something
that should be exposed as an algorithm in JCA, because it is too broad.
SP 800-108 is more of a toolbox that can be used to construct KDFs.
Particular specializations of SP 800-108 are widely used, and they will
get names that can be used in getInstance. For example, HKDF-Expand is a
particular specialization of SP 800-108.
So I think the existing pattern of using algorithm names to specify
concrete algorithms should work just as well in this API as it does in
the rest of JCA. Of course, more flexibility in the API is a nice
feature, but supporting this level of generality may be out of scope for
this effort.
>
> Mike
>
>
>
>
More information about the security-dev
mailing list