<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 11/16/2017 12:47 AM, Michael StJohns wrote:<br>
</p>
<blockquote type="cite"
cite="mid:1b92fa9d-3b0e-88af-30ef-8b0e7e52ca0f@comcast.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>
</blockquote>
<br>
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?<br>
<br>
</body>
</html>