KDF API review, round 2

[Michael StJohns]

On 11/15/2017 11:43 AM, Jamil Nimeh wrote:
> Hello all,
>
> Thanks to everyone who has given input so far.  I've updated the 
> KeyDerivation API with the comments I've received.  The new 
> specification is here:
>
> Text: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.02.txt
> Javadoc: http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.02/
>
> In terms of high level changes:
>
>   * Moved to a getInstance/init usage pattern similar to Mac,
>     KeyAgreement, Cipher, etc.  This allows KDF objects to be reused
>     with different parameters by reinitializing.
>   * Name change: DerivedKeyParameterSpec --> DerivationParameterSpec
>   * Keys returned by derivation methods are now java.security.Key
>     rather than SecretKey
>   * Provided additional derivation methods to support non-key based
>     output: deriveData, deriveObject
>   * Added a new constructor to DerivationParameterSpec to support the
>     Object return type.
>
> Thanks,
> --Jamil


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 want to do a worked example from instantiation to use to make sure 
this covers the corner cases.  Give me a day....  I'm currently in 
Singapore.

Mike






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