Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

[Greg Hudson <[e-mail]>]

On 04/08/2015 05:26 PM, Benjamin Kaduk wrote:
> I did not go on a full trawl through the archives, but
> http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies
> that NIST is generating a document covering "what you get from what you
> used" indicating that SHA-256 only gives you 128 bits, under some set of
> assumptions.

I do not understand what assumptions would yield a security level of 128
bits from SHA-256 truncated to 192 bits, and a security level of 192
bits from SHA-384 truncated to 192 bits.  If there is a concern about
birthday attacks on the integrity tag, then we can't get away with
truncating at all; we would need to send a 256-bit tag for the 128-bit
security level, and a 384-bit tag for the 192-bit security level.

I wonder if NIST finished its document in the interim.

>> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This was probably a dumb question, and really devolves into "why use a
256-bit PRF output length?"  For the 192-bit security level, Ki and Kc
are used to generate a 192-bit tag, but Kp is used to generate a 256-bit
PRF.

[Regarding truncation of the PRF output:]
> I think there is some desire to always truncate SHA-2 results in half,
> though, for the reasons mentioned above.

I would like to better understand these reasons.

> So random-to-key() only applies for generating base keys, and the
> derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Yes.  RFC 3961 defines random-to-key() as producing a protocol key.  It
is probably a conceptual error that RFC 3961 section 5.1 uses
random-to-key() as the last step of its key derivation function.  That
error would be especially confusing in the new context, where derived
HMAC keys can have different lengths than protocol keys.

> Or is the argument rather that since we are not using the simplified
> profile, we just don't need random-to-key() at all because we are defining
> things manually and can make use of the fact that it is the identity
> function for these enctypes?

No, we need a random-to-key(); it is part the RFC 3961 definition of an
encryption algorithm profile.  By contrast, key derivation is not part
of this definition; it's just an internal feature of every
non-single-DES encryption type so far.

>> sloppy because it depends on context; instead of taking a length
>> parameter, it uses an implicit length based on what operation the
>> invoker is performing.  In a similar vein, section 3 talks about what
>> the input constant is for each derivation use; this is not the case for
>> RFC 3961 or RFC 6803 and seems out of place.

> So you want to rely just on the (type of the) key being derived and not
> mention the last octet of the constant?  I think that would be a valid way
> to specify things, but want to confirm the nature of your comment.

My suggestion is to:

* Give the key derivation function KDF-HMAC-SHA2() an explicit length
parameter, and remove the discussion of what its value is for each use.
 Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in
the document.  This argument will probably need to be given
symbolically, as it varies between the 128-bit and 192-bit security levels.

* Remove the discussion of what the constant values are from section 3.

>> I have several concerns about the presentation of the test vectors:
>>
>> * The PRF test vectors do not list a base key; instead it lists a Kp
>> value.  This requires tests to exercise only a component of the PRF
>> implementation, which may be inconvenient.  The base keys are present in
>> the key derivation test vectors, but this is not immediately clear.

> We could add text so the PRF test vectors say "Kp value (repeated from
> above):"; would that help?

I think it would be better to explicitly list the base key.  If it
happens to be the same as the base key from a previous test vector,
that's not really important.

>> * The encryption test vectors do not list base keys and key usages;
>> instead they only list "AES key" and "HMAC key" values which are
>> presumably Kc and Ki.  For the first 128-bit test vector, the base key
>> and usage is recoverable from the key derivation test vectors, but that
>> does not appear to be the case for any of the other encryption test
>> vectors.  Because of this, I only verified the first encryption test vector.

> Hmm.  I don't really want to propose removing test vectors to replace them
> with new ones, but could we add some additional test vectors which do
> possess the desired properties?  (I.e., that the Kc and Ki are listed in a
> previous test vector from base key and usage, or that they are test
> vectors starting from base key.)

I don't think there's anything precious about the currently listed test
vectors.  If the draft authors possess the base keys they used for the
encryption test vectors, they can provide them; otherwise they can
generate new test vectors and we can discard the old ones.  Including
encryption test vectors with missing base keys just seems frustrating to
an implementor.