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

[Michael Jenkins <[e-mail]>]

Hi, sorry for the silence. I've been on travel and I wanted to make sure I
got one of the original authors to help respond. So, we should be able to
address all of Greg's concerns shortly. In the meantime, I can comment
generally if simplistically on two things:

Bit string lengths and bits-o'-security: When this draft was originally
introduced to kitten, it was stated that it was to support
draft-burgin-kerberos-suiteb <
http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So
there's an implicit presumption that one is working in one of two modes,
192-bit or 128-bit security, and consequently using either SHA-384 or
SHA-256, respectively.

In general, though, it's designed to make sense - you can't use SHA-256 to
get a 192 bit key because a SHA-256 output has at most 128 bits of security
no matter how you slice it. I am not an expert in attacks on hashes nor on
hash-function construction (boy howdy!), so I'm not going to argue about
whether this particular application is susceptible to this-or-that attack -
ultimately the answer is "because Suite B". I'm not saying that as a
hammer; I'm saying that's how the thing was pitched and accepted as a
work-item back at version -02.

Test vectors: I can nearly guarantee (see inheritance disclaimer above)
that the Ke for the encryption test vector sets beyond the first 128-bit
one came straight out of /dev/random, no doubt based on the fact that it
was easier to do so than to figure out how to get access to Kelley's
abandoned workfiles after he left for greener pastures (go him!). I can
regenerate them taking a more soup-to-nuts approach.

Mike J

On Wed, Apr 8, 2015 at 6:48 PM, Greg Hudson <[e-mail]> wrote:

> 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.
>
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten
>



-- 
Mike Jenkins
[e-mail] - if you want me to read it only at my desk
[e-mail] - to read everywhere else
443-634-3951