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

Nico Williams <nico@cryptonector.com> Wed, 15 April 2015 19:30 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F80D1A8905 for <kitten@ietfa.amsl.com>; Wed, 15 Apr 2015 12:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.334
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqUDFzmzWri3 for <kitten@ietfa.amsl.com>; Wed, 15 Apr 2015 12:30:00 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1D1A88FE for <kitten@ietf.org>; Wed, 15 Apr 2015 12:30:00 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2B10E50808C; Wed, 15 Apr 2015 12:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=RTz1cdKwG4pCxU LW1taM4K2mvo4=; b=n0iqaCANEjKkk0h9LmVe1cZ+ro0tYzyFzLSeauzvRvAq1B F8fhyXKe59rK8T+BQINJemZWs/EAGM2Oro9SJ66fVmUQDNHT8C1pyjV+tFuUSVn/ Z8irUBNh519gVmAsgQeL9dOBmBzwpwNte9dbGW94pghfY5jDsShuYU/wm39lc=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (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 <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20150415192957.GB29890@localhost>
References: <alpine.GSO.1.10.1503301227280.22210@multics.mit.edu> <551D6C35.4080108@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <551D6C35.4080108@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/OEUOVogjj83VC55EcivIVckGGIw>
Cc: kitten@ietf.org
Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=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
aes256-cts-hmac-sha512-256.

> * 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.)

Nico
--