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

Greg Hudson <> Wed, 08 April 2015 22:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9ADE81A90E8 for <>; Wed, 8 Apr 2015 15:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v0DfA_88nkV7 for <>; Wed, 8 Apr 2015 15:48:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1907B1A90E6 for <>; Wed, 8 Apr 2015 15:48:45 -0700 (PDT)
X-AuditID: 12074424-f79f56d000000da5-00-5525b04be1e7
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D5.A9.03493.B40B5255; Wed, 8 Apr 2015 18:48:44 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t38Mmc9j013622; Wed, 8 Apr 2015 18:48:38 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t38Mma6I008143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2015 18:48:37 -0400
Message-ID: <>
Date: Wed, 08 Apr 2015 18:48:36 -0400
From: Greg Hudson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Benjamin Kaduk <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrOuzQTXUYMV5Joujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/PzK+aCKRoVC579YGpg7FLoYuTkkBAwkZi1fiU7hC0mceHe erYuRi4OIYHFTBJLGj+zQjgbGCWuTX7IDOEcZpL4+GYlUBkHB6+AmsT6HwkgJouAqsSBackg g9gElCXW79/KAmKLCoRJzF53kRHE5hUQlDg58wlYXERASWLx2RY2EJtZQFjiwva9rCC2sICL xKwtK9ghVk1ilJgzbxczSIJTwEli79L17BANehI7rv9ihbDlJZq3zmaewCg4C8mOWUjKZiEp W8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyMoWNldVHYwNh9SOsQowMGo xMMrsFglVIg1say4MvcQoyQHk5Io77mVqqFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgdVgPl eFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeFesA2oULEpNT61Iy8wp QUgzcXCCDOcBGn4dpIa3uCAxtzgzHSJ/ilFRSpz3NEhCACSRUZoH1wtLJq8YxYFeEeZlXA9U xQNMRHDdr4AGMwEN5n+mBDK4JBEhJdXAyMuY8MB/R/CUM3c+LlResSayLPqzdMadhfsb1sWl mWnq9L04P+fumWz18Hkv2xufntfuF05zZu2+acLc1bNBP+HGl0dS95qXXpJce7Gt2/78/Hnn NylU3/Zjmnbiana1/TrmY82Jf4NPum02i0rQfryl+usKIyY/kfnbpm7bWt+qwaEo4FlWp8RS nJFoqMVcVJwIAIggvfwBAwAA
Archived-At: <>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Apr 2015 22:48:47 -0000

On 04/08/2015 05:26 PM, Benjamin Kaduk wrote:
> I did not go on a full trawl through the archives, but
> 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

[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.