<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/15/2017 11:43 AM, Jamil Nimeh
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f0a0af4c-75c7-0c26-5467-c8d4dcc6e81e@oracle.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Hello all,<br>
<br>
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:<br>
<br>
Text: <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ejnimeh/reviews/kdfspec/kdfspec.02.txt"
moz-do-not-send="true">http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/kdfspec.02.txt</a><br>
Javadoc: <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ejnimeh/reviews/kdfspec/javadoc.02/"
moz-do-not-send="true">http://cr.openjdk.java.net/~jnimeh/reviews/kdfspec/javadoc.02/</a><br>
<br>
In terms of high level changes:
<ul>
<li>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.</li>
<li>Name change: DerivedKeyParameterSpec -->
DerivationParameterSpec</li>
<li>Keys returned by derivation methods are now
java.security.Key rather than SecretKey<br>
</li>
<li>Provided additional derivation methods to support non-key
based output: deriveData, deriveObject</li>
<li>Added a new constructor to DerivationParameterSpec to
support the Object return type.</li>
</ul>
Thanks,<br>
--Jamil<br>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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"))<br>
</p>
<p><br>
</p>
<p>Here's the model I'm thinking about:</p>
<blockquote>
<p>SP800-108 is a parameterized set of Key derivation functions
which goes something like:</p>
<blockquote>
<p>Pick either Counter or Feedback<br>
</p>
<p>Pick the PRF (e.g. HMAC-SHA256, AES-128-CMAC, etc)<br>
Pick the size of the counter and endianness: (e.g. Big endian
Uint16)<br>
</p>
Pick the size and endianness of L<br>
<br>
Pick whether the counter precedes or follows the fixed data (for
counter mode).<br>
Pick whether the counter is included and whether it precedes or
follows the fixed data (for feedback mode)<br>
</blockquote>
</blockquote>
<br>
Taken together those instantiation parameters define a particular
KDF model.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Mike<br>
<br>
<br>
<br>
<br>
<blockquote>
<blockquote><br>
</blockquote>
<br>
</blockquote>
</body>
</html>