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

Benjamin Kaduk <kaduk@MIT.EDU> Fri, 17 April 2015 21:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 904631B2F0F for <>; Fri, 17 Apr 2015 14:23:17 -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 gKaVed31AAE7 for <>; Fri, 17 Apr 2015 14:23:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B11C1B2F0B for <>; Fri, 17 Apr 2015 14:23:15 -0700 (PDT)
X-AuditID: 1209190c-f792b6d000000d1f-cc-553179c287c9
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 20.EA.03359.2C971355; Fri, 17 Apr 2015 17:23:14 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3HLND2X006236; Fri, 17 Apr 2015 17:23:13 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3HLNBRQ029915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 17:23:12 -0400
Received: (from kaduk@localhost) by ( id t3HLNAbs016012; Fri, 17 Apr 2015 17:23:10 -0400 (EDT)
Date: Fri, 17 Apr 2015 17:23:10 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrHuo0jDU4OUhcYs/KyexWRzdvIrF Ytm3q2wWv/qaWR1YPHbOusvusWTJTyaPk33nWQOYo7hsUlJzMstSi/TtErgyDs1fzljwS6Oi f/ZkpgbGKwpdjJwcEgImEuveNTFD2GISF+6tZ+ti5OIQEljMJLF64V5GCGcjo8TW/3fZIZxD TBJNyz9AlTUwSlyetpEJpJ9FQFvi3KsLYLPYBFQkZr7ZyAZiiwgIS+ze+o4ZpIFZYBKjxK5v vYwgCWEBF4lZW1YAjeXg4BRwkrj9OATE5BVwlFhxtxSkQgjIfLnwCth4UQEdidX7p7CA2LwC ghInZz4Bs5kFtCSWT9/GMoFRcBaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0DfVy M0v0UlNKNzGCA1mSZwfjm4NKhxgFOBiVeHgPxBuECrEmlhVX5h5ilORgUhLl1c01DBXiS8pP qcxILM6ILyrNSS0+xCjBwawkwjsdJMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1 CCYrw8GhJMFrXQHUKFiUmp5akZaZU4KQZuLgBBnOAzT8DEgNb3FBYm5xZjpE/hSjopQ470qQ hABIIqM0D64XlmheMYoDvSLMuwCkigeYpOC6XwENZgIaXLrDAGRwSSJCSqqBUbp1WsAl5fI8 KaV7ssxhOi8iH0sXrOe9G+p+4HhDUY/J9vB59/Xe3H0lWpT14vLBzl2Sssoxaas3852f0Xmt yj90ltxTzr//rC8+nOS83OnYqVkliQW975lZblzxT94Y/r89zqatrEPgvMqEG47JjT8/TuU5 +ea2mYqjbIGGB2PL19tZyqXblViKMxINtZiLihMB49n1Xg8DAAA=
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: Fri, 17 Apr 2015 21:23:17 -0000

We got a number of comments and questions in this last call.  I will try
to summarize them and the response to them, below.  Please let me know if
I have missed something or inaccurately represented someone's statements.


* Greg asked about using SHA-256 instead of SHA-384 for 192-bit truncated

There was a lot of discussion on this point.  The conclusion seems to be
that, when used with a has function that is a PRF, the HMAC construction
is not dependent on collision resistance and therefore the security level
is capped by the size of the input key (or the hash output length).
(Note, however, that a hash which is not collision resistant to the
2^(n/2)-bit level, such as SHA-1, is as a consequence not a PRF.)  So,
while it would be cryptographically fine to use HMAC-SHA2-256() truncated
to 192 bits as message authentication tag, we will still retain
HMAC-SHA2-384() at the 192-bit security level to be consistent with the
Suite B recommendations.  (It may also be faster in some situations on
some hardware, but this is hard to make general statements about.)

* Greg asked why Ki and Kc are 192-bit but Kp is 256-bit, or alternately
"why use a 256-bit PRF output length?", but later retracted that question,
as there are reasons why a 256-bit Kp makes sense that do not apply to Ki
and Kc.  "But why truncate the PRF at all?" remains.

There is not really an issue here anymore.  Ki and Kc are 192-bit derived
keys because they are used to derive 192-bit message authenticity tags.
The base key, Ke, and Kp are 256-bits.  It is convenient to make the base
key 256 bits, since we use aes256, and will need 256-bit encryption keys;
making the base key smaller than that seems silly in some sense.  Ke has
to be 256 bits since it is in the path to the aes256 encryption keys as
well.  Kp is 256 bits because the PRF output should be suitable for key
generation, and there is no reason to reduce the number of bits of
keyspace at this point.  (But see the next item.)

* Greg asked why the PRF output length is 128/256 bit instead of the full
hash width.

There does not seem to be any reason to truncate the HMAC output, here.
The output length is supposed to be what is convenient for the enctype,
and there is precedent for not being a multiple of the key size.  It would
be good to get acknowledgement from the authors that this will go in the
next revision.

* Greg noted that random-to-key() is used in computing Ki and Kc, but for
the AES256 variant, random-to-key() formally only produces a (256-bit)
base key, so this is slightly problematic.

The random-to-key() function for this enctype is the identity function,
and the uses in section 3 are entirely internal to the implementation;
there is no need to write random-to-key() in these places.  We can safely
just write things like KDF-HMAC-SHA2(key,constant,k) = k-truncate(K1).

* Greg wants base keys and key usages for the test vectors instead of
intermediate keys.

General agreement; new test vectors will be generated that include base
keys and derivation constants.

* I noted an instance of "the use of [...] AES-256 with a 192-bit key"
which should be reworded.

No objections; will the document editor please take note.

* Greg suggested giving KDF-HMAC-SHA2() an output length parameter.

Michael thinks this is probably reasonable, and may help the readability
of the document.  It sounds like we will go forward with this approach.

* Greg wants to remove discussion of the constant values from section 3.

Also no objections and probably reasonable.

* Jeff A. asked if we have independent cryptographic review

Nico and I claim that we are using well-understood building blocks in
well-understood ways, and no additional review is needed.  Jeff A. has not
had a chance to reply to these claims yet.

* Jeff A. cares strongly about interoperability and test vector

Greg and Weijun have published python and java code respectively, which
verify the test vectors, but are not quite enough for interoperability
testing (?).  The authors had java and python implementations to verify
the test vectors, which are not (?) published.  I claim this is sufficient
for now, and Jeff A. has not had a chance to reply yet.

* Michael plans to update the draft in response to comments, and expand
the test vectors.

There is much rejoicing.


That seems to leave us with the following action items:

For the document editor:
* remove truncation from the PRF output and use the natural hash output
* remove the use of random-to-key() and discussion of constant values from
section 3
* add an output length argument to KDF-HMAC-SHA2() and adjust text
* update test vectors to include base keys and key usage values for all
test cases
* reword the text discussing aes256 with 192-bit keys

For Jeffrey Altman:
* comment about the status of the crypto review and the interoperability
testing in light of other comments that have come in on those points.