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

Greg Hudson <> Fri, 10 April 2015 00:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 150331B37BE for <>; Thu, 9 Apr 2015 17:12:03 -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 vZh_pAC3v2hS for <>; Thu, 9 Apr 2015 17:12:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F38631B37BC for <>; Thu, 9 Apr 2015 17:12:00 -0700 (PDT)
X-AuditID: 1209190c-f792b6d000000d1f-5e-5527154ff75a
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 F3.E0.03359.F4517255; Thu, 9 Apr 2015 20:11:59 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3A0BrYP026351; Thu, 9 Apr 2015 20:11:54 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3A0BoGg006936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Apr 2015 20:11:52 -0400
Message-ID: <>
Date: Thu, 09 Apr 2015 20:11:50 -0400
From: Greg Hudson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Michael Jenkins <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1vUXVQ81eDLV3OLo5lUsFsu+XWWz 2Pj+FKMDs8fOWXfZPZYs+cnksbX5H2MAcxSXTUpqTmZZapG+XQJXxsU7cgVfRCvmT33C1sD4 TrCLkZNDQsBEYsr2JkYIW0ziwr31bF2MXBxCAouZJG6duMcK4WxglLh8YBdU5jCTxP75M9hA WngF1CQOT/jACmKzCKhKHJq3CsxmE1CWWL9/KwuILSoQJjHt93NWiHpBiZMzn4DFRQQMJBZN Wgc2h1kgX2LDlC1gZwgLuEjM2rKCHWLZJ0aJBVO+M4MkOAUCJbZ+OMYM0aAu8WfeJShbXqJ5 62zmCYyCs5DsmIWkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0DfVyM0v0UlNKNzGC w1qSZwfjm4NKhxgFOBiVeHhffFMNFWJNLCuuzD3EKMnBpCTKe41LPVSILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCO8ZDqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IE r7UIUKNgUWp6akVaZk4JQpqJgxNkOA/QcAWQGt7igsTc4sx0iPwpRkUpcd6nwkAJAZBERmke XC8s7bxiFAd6RZhXCqSdB5iy4LpfAQ1mAhr83FANZHBJIkJKqoExYnrjls0356xRu6RpXfFZ 6UOb5dzcZy72LtM/buW0iN4VyhQjnCWvVSC+tprhguafRblXy45tfi2noOaa/6vb+k9/RpP+ AZ6VPQXGnm/MjhxijljuatR5pXv9m133SgObloUeKzs+8cheBrcF/N8+3pxx9PkzeaYXW4yX zM9fWf9x2k9rBa8eJZbijERDLeai4kQAzwDonBYDAAA=
Archived-At: <>
Cc:, "" <>
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, 10 Apr 2015 00:12:03 -0000

On 04/09/2015 06:21 PM, Michael Jenkins wrote:
> 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
> <>. 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. 

I am not familiar with what Suite B requires in detail.  Looking at
I do see that Suite B indicates the use of SHA-384 for TOP SECRET.  I
assume that it requires this because the weakest inherent aspect of a
hash is its collision resistance, and SHA-384 has (we hope) a collision
resistance strength of 192 bits.  Some uses of a hash may not require
collision resistance, but using SHA-384 means you're covered regardless.

However, SHA-384 truncated to 192 bits does not have a collision
resistance strength of 192 bits; it has a collision resistance strength
of 96 bits.  This is described in detail in SP 800-107 section 5.1,
which is referenced by FIPS 180-4 section 7.

I don't think any meaningful review would deem
192-truncate(HMAC-SHA-384(k, m)) to be stronger than
192-truncate(HMAC-SHA-256(k, m)) by any metric.

> 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 think it very much does matter how you slice it.  For key derivation
using an HMAC, collision resistance is not required, so it is entirely
reasonable to use SHA-256 to generate a 192-bit key.  In fact, the key
derivation function used in this draft (from SP 800-108 section 5.1) can
work securely even if more keying material is required than the HMAC
output size.

For the encryption integrity tag and checksum, collision resistance may
be required for Suite B compliance (but I don't really know).  But as
mentioned above, if we're going to truncate the HMAC result down to 192
bits, we cannot achieve collision resistance strength greater than 96
bits no matter what hash function we use in the HMAC.

In conclusion, to the best of my knowledge:

* If the goal is to meet a checklist of Suite B requirements, using
SHA-384 over SHA-256 internally might be necessary, but it really is
just a meaningless checklist tick.  Moreover, the small integrity tag
and checksum lengths could mean that the draft doesn't actually satisfy
Suite B--I can't speak confidently either way on that point.

* If the goal is to achieve some real security strength, using truncated
SHA-384 is not an improvement over using truncated SHA-256.