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
