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

Nico Williams <nico@cryptonector.com> Wed, 15 April 2015 19:54 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 5C8511A89B8 for <kitten@ietfa.amsl.com>; Wed, 15 Apr 2015 12:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 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, 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 pRFuinTvt-LN for <kitten@ietfa.amsl.com>; Wed, 15 Apr 2015 12:54:51 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 982631A89AF for <kitten@ietf.org>; Wed, 15 Apr 2015 12:54:51 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 61156360094; Wed, 15 Apr 2015 12:54:51 -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=AjoF6rFTbutBTN jU7R7Wd5t45h8=; b=EoBFeamoetpBBOVnBnTSdTVcYCxVcQVIvnNzceeF8KcIbO ZXOSNJFDSjA+/pdVeEbgljDCgnNiVopAADxa/dtQwj+0SS4s8kzE0OaF6RiG/WQ8 Q/DeAvzAGReJ8IdpNI7m95SCOfpIgL0AWlc6qwMBane/5/jLo9KSuTfd8v+FM=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 2512F360093; Wed, 15 Apr 2015 12:54:49 -0700 (PDT)
Date: Wed, 15 Apr 2015 14:54:48 -0500
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20150415195448.GC29890@localhost>
References: <alpine.GSO.1.10.1503301227280.22210@multics.mit.edu> <551D6C35.4080108@mit.edu> <alpine.GSO.1.10.1504081626110.22210@multics.mit.edu> <5525B044.8070509@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5525B044.8070509@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/5DuZ1pUEuUfSVWR5y2GwC1eIASw>
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:54:52 -0000

On Wed, Apr 08, 2015 at 06:48:36PM -0400, Greg Hudson wrote:
> I do not understand what assumptions would yield a security level of 128
> bits from SHA-256 truncated to 192 bits, and a security level of 192
> bits from SHA-384 truncated to 192 bits.  If there is a concern about
> birthday attacks on the integrity tag, then we can't get away with
> truncating at all; we would need to send a 256-bit tag for the 128-bit
> security level, and a 384-bit tag for the 192-bit security level.

I expect HMAC-SHA-256 with 128-bit HMAC keys provides 128-bit security
against forgeries (which is all we're after if we encrypt-then-MAC) no
matter length the result is truncated to as long as that length is 128
or more bits.

The reason is: the attacker has a 128-bit key search space, and any
forgery attack that requires more work than a key brute-force attack is
not worth it, so using a MAC length of more than 128 bits is not likely
to be useful (it will cause defenders to waste bandwidth) unless there
are forgery attacks at least a few bits better than the MAC length, for
HMAC with any given MAC length.

The critical thing here is the size of the HMAC key.

Perhaps HMAC-SHA256-192 with 192-bit keys could also provide 192-bit
security against distinguishing attacks and forgeries.  But if there are
such attacks depending only attacking the hash against collisions then
HMAC-SHA256-192 can't provide 192-bit security against forgeries -- it
seems prudent to assume such attacks.

ISTM prudent to use HMAC with keys of size matching the advertised
collision resistance of the base hash function and then truncate the
result to that same size.

So, HMAC-SHA256-128 w/ 128-bit keys is OK, but HMAC-SHA256-192 is not
(even if the keys are 192-bit).

Nico
--