KDF API review, round 2

[Adam Petcher]

On 11/16/2017 12:47 AM, Michael StJohns wrote:

> This is pretty close, but I think you need to add an 
> AlgorithmParameters argument to each of the getInstance calls in 
> KeyDerivation - or require each KDF to specify a default model - not 
> all KDFs are fully specified in a given document.
>
> Alternately, you could use the .setParameter/.getParameter model of 
> signature,  but it may be that underlying code will actually be 
> creating a whole new instance.  (E.g. getInstance("NIST-SP800-108") vs 
> getInstance("NIST-SP800-108-Counter") vs 
> getInstance("NIST-SP800-108/Counter"))
>
>
> Here's the model I'm thinking about:
>
>     SP800-108 is a parameterized set of Key derivation functions which
>     goes something like:
>
>         Pick either Counter or Feedback
>
>         Pick the PRF (e.g. HMAC-SHA256, AES-128-CMAC, etc)
>         Pick the size of the counter and endianness:  (e.g. Big endian
>         Uint16)
>
>         Pick the size and endianness of L
>
>         Pick whether the counter precedes or follows the fixed data
>         (for counter mode).
>         Pick whether the counter is included and whether it precedes
>         or follows the fixed data (for feedback mode)
>
>
> Taken together those instantiation parameters define a particular KDF 
> model.
>
> Then for the .init() call, the kdfParams is where the Label and 
> Context data go (what HKDF calls 'info').  For most KDFs this could 
> just be a byte array.
>
> For HKDF the getInstance must specify an underlying hash function - by 
> definition mode is feedback, the size of the counter is fixed, L is 
> not included in the base calculation.  (TLS1.3 uses HKDF and makes L a 
> mandatory part of the HKDF).

I don't like the idea of putting algorithm parameters in getInstance, 
because we don't have this pattern in JCA, and it doesn't seem like it 
is necessary here. In your example above, the first set of parameters 
are somehow different from the second set, but it is not clear how. 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171116/91f8f004/attachment.htm>