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

Nico Williams <> Wed, 15 April 2015 19:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F80D1A8905 for <>; Wed, 15 Apr 2015 12:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.334
X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VqUDFzmzWri3 for <>; Wed, 15 Apr 2015 12:30:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 97F1D1A88FE for <>; Wed, 15 Apr 2015 12:30:00 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 2B10E50808C; Wed, 15 Apr 2015 12:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=RTz1cdKwG4pCxU LW1taM4K2mvo4=; b=n0iqaCANEjKkk0h9LmVe1cZ+ro0tYzyFzLSeauzvRvAq1B F8fhyXKe59rK8T+BQINJemZWs/EAGM2Oro9SJ66fVmUQDNHT8C1pyjV+tFuUSVn/ Z8irUBNh519gVmAsgQeL9dOBmBzwpwNte9dbGW94pghfY5jDsShuYU/wm39lc=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 2BFA8508084; Wed, 15 Apr 2015 12:29:58 -0700 (PDT)
Date: Wed, 15 Apr 2015 14:29:57 -0500
From: Nico Williams <>
To: Greg Hudson <>
Message-ID: <20150415192957.GB29890@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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, 15 Apr 2015 19:30:01 -0000

On Thu, Apr 02, 2015 at 12:20:05PM -0400, Greg Hudson wrote:
> * For the 192-bit security level, why use SHA-384 and truncate to 192
> bits?  Why not use SHA-256 and truncate to 192 bits?

I've no objection to the construction

    MAC(k, x) = trunc(HMAC(k,H), output_size(H)/2.

It's simple and obvious.

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This I dont' understand.  The HMAC key should be the same size as the
cipher key.

I suspect this is an editing error.

There should be two or three enctypes:

 - aes128-cts-hmac-sha256-128

   AES with 128-bit keys, and
     MAC = trunc-128(HMAC-SHA256) with 128-bit HMAC keys

 - aes192-cts-hmac-sha384-192

   AES with 192-bit keys, and
     MAC = trunc-192(HMAC-SHA384) with 192-bit HMAC keys

 - aes256-cts-hmac-sha512-256

   AES with 256-bit keys, and
     MAC = trunc-256(HMAC-SHA512) with 256-bit HMAC keys

Generally, the security level of the components should match the overall
security level of the enctype.

I suppose an aes256-cts-hmac-sha384-192 would be OK, but only if we
reject AES-192 and such an enctype is noticeably faster than

> * Why use 128/256-bit PRF output lengths?  Why not just output the full
> hash?  It can't be for consistency with RFC 3962, as
> aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
> out of some desire to consistently truncate SHA-2 results in half, or we
> would have 128/192-bit output lengths.

Eh?  The KDF is a truncation of the PRF.  The PRF is not truncated.

>From the draft:

   When the encryption type is aes128-cts-hmac-sha256-128, the output
   key length k is 128 bits for all applications of KDF-HMAC-SHA2(key,
   constant) which is computed as follows:

     K1 = HMAC-SHA-256(key, 00 00 00 01 | constant | 00 | 00 00 00 80)
     KDF-HMAC-SHA2(key, constant) = random-to-key(k-truncate(K1))

The "SHA2" there must be a cut-n-paste error, otherwise it looks right
to me.

(RFC3962 does not define a PRF, just a KDF.)