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?

Reply via email to