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

Greg Hudson <> Thu, 16 April 2015 09:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2EE351B2E04 for <>; Thu, 16 Apr 2015 02:21:33 -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 1lz2QyHlnWy9 for <>; Thu, 16 Apr 2015 02:21:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF6751B305D for <>; Thu, 16 Apr 2015 02:21:29 -0700 (PDT)
X-AuditID: 12074425-f79ca6d000000e5e-48-552f7f18e8e7
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 77.5A.03678.81F7F255; Thu, 16 Apr 2015 05:21:28 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3G9LR1q008900; Thu, 16 Apr 2015 05:21:28 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3G9LPsu002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2015 05:21:27 -0400
Message-ID: <>
Date: Thu, 16 Apr 2015 05:21:25 -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 Peck <>
References: <> <20150415205159.GF29890@localhost> <> <20150415210538.GG29890@localhost> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrStRrx9qcG23usXRzatYLH71NbM6 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBk7pj1kKtgvVHHy513WBsY3fF2MnBwSAiYS G2ZuYYOwxSQu3FsPZHNxCAksZpK4c3IlO4SzkVHi8LlXYFVCAkeYJP5fkgexeQXUJBperWIB sVkEVCXm3z4CZrMJKEus378VzBYVCJOY9vs5K0S9oMTJmU/A4iJANf8fTGcCsZkFhCUubN8L ViMs4CIxa8sKqMVNTBIN3yAGcQoEShxquMYG0aAnseP6L1YIW16ieets5gmMgrOQ7JiFpGwW krIFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgkKY3UV1B+OEQ0qHGAU4 GJV4eD0S9EOFWBPLiitzDzFKcjApifKyFAKF+JLyUyozEosz4otKc1KLDzFKcDArifAeTwfK 8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8N6uBWoULEpNT61Iy8wp QUgzcXCCDOcBGn4XpIa3uCAxtzgzHSJ/ilFRSpz3GkhCACSRUZoH1wtLMa8YxYFeEeZlrQOq 4gGmJ7juV0CDmUCuDtQFGVySiJCSamBMOVf31nfVrOSF4px5GUFMpyumnOlWbTssMXnV38Ps e2917VGavfxzoLbLzZ3nn0+JSZ79jnPbpTsmR/VVlF/0ztb0t5rz9Mz27K1svhNZNx1SfuW9 u2Hv6zlM6hfXvWZz0OJYsFJPf/Prkgap2zvS5xS58ehdu/Ph1ZwiiakGdZZHWyd2NxjPUmIp zkg01GIuKk4EAIjPkhoMAwAA
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: Thu, 16 Apr 2015 09:21:33 -0000

On 04/15/2015 10:20 PM, Michael Peck wrote:
> In the case of our proposed Kerberos enctypes, we're using the hashes
> with HMAC for message authentication and for a KDF so collision
> resistance is not a factor - in this case, SHA-384 truncated to 192 bits
> appears to add no cryptographic value over SHA-256 truncated to 192 bits.  
> However, our preference would still be to keep the hash choice as is for
> consistency with the Suite B pairing of AES-256 with SHA-384.  This
> could theoretically enable someone using just that option to not even
> need SHA-256, and might also help avoid confusing compliance assessors.

I can accept the reasoning that the choice is about Suite B pairing and
not cryptographic strength.  As Viktor notes, the performance impact of
using SHA-384 over SHA-256 is a mixed bag; it is likely to be slower for
computing derived keys and PRFs, but faster for computing integrity tags
and checksums for large messages.

> Kp is used for the Kerberos pseudo-random function (PRF).  
> RFC3961 states that the PRF output "should be suitable for use in key
> generation" - if i recall correctly, our thinking here was that we
> didn't know what types of keys could potentially be derived from the PRF
> output, so we'd output the full 256 bits (whether the strength of the
> PRF output is actually 256 bits would of course depend on how the
> base-key is generated/derived) in case the PRF might be used to generate
> an AES-256 key - figured no need to drop bits even if our expected
> strength of the enctype overall is 192 bits.

Okay, but why truncate the PRF output at all?  Why not make the PRF
output 256 bits for aes128-cts-hmac-sha256-128 and 384 bits for

Generally speaking, the size of the PRF output is something convenient
to the enctype, and a construction like the RFC 6112 PRF+ is used to
construct however much keying material is necessary by iterating and
truncating the PRF.  There is no need for the enctype to restrict its
output length to the input key length.  (Of course the entropy of the
output is limited to the entropy of the input key.)

For comparison, RFC 4757 defines its PRF as HMAC-SHA1(K, S) and outputs
160 bits for a 128-bit input key.

I agree that Kp should be 256 bits for aes256-cts-hmac-sha384-192; that
was a dumb question.