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

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 16 April 2015 06:46 UTC

Return-Path: <viktor1dane@dukhovni.org>
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 567121B2A3B for <kitten@ietfa.amsl.com>; Wed, 15 Apr 2015 23:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
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 935uAewvnc3I for <kitten@ietfa.amsl.com>; Wed, 15 Apr 2015 23:46:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792091B2A2A for <kitten@ietf.org>; Wed, 15 Apr 2015 23:46:16 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 96F89283032; Thu, 16 Apr 2015 06:46:14 +0000 (UTC)
Date: Thu, 16 Apr 2015 06:46:14 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: kitten@ietf.org
Message-ID: <20150416064614.GB17637@mournblade.imrryr.org>
References: <alpine.GSO.1.10.1503301227280.22210@multics.mit.edu> <20150415205159.GF29890@localhost> <alpine.GSO.1.10.1504151657340.22210@multics.mit.edu> <20150415210538.GG29890@localhost> <CAKbsn2+qc50NeJ5K1qHbPzAvk-a7AuQJPUbairp6gWcMH993Hw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKbsn2+qc50NeJ5K1qHbPzAvk-a7AuQJPUbairp6gWcMH993Hw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/5UAXAGMA742y8DPMjZsmjTM9A-Y>
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
Reply-To: kitten@ietf.org
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: Thu, 16 Apr 2015 06:46:18 -0000

On Wed, Apr 15, 2015 at 10:20:56PM -0400, Michael Peck wrote:

> 1. HMAC-SHA-384 truncated to 192 bits versus HMAC-SHA-256 truncated to 192
> bits :
> 
> Suite B was our motivation for proposing the two encryption types.
> Suite B pairs AES-128 with SHA-256, and pairs AES-256 with SHA-384.  When
> used in the digital signature context, SHA-256 provides an expected 128 bit
> security level, and SHA-384 an expected 192 bit security level because of
> the dependence on collision resistance.
> 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.
> (NIST SP 800-107 has a discussion of hash strengths as used in various
> contexts :
> http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf )

In terms of throughput, interestingly enough SHA2-512 is faster or
bulk data processing, because of its wider state, which means more
data is processed per step.  (Tested with OpenSSL 1.1 dev branch):

    $ openssl speed sha256
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    sha256           41170.10k    90881.05k   154050.73k   187984.90k   200602.63k

    $ openssl speed sha512
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    sha512           27398.45k   107324.81k   167345.58k   234789.84k   265300.65k

Similar gain reported at:

    https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions

So I guess there's no harm in using SHA2-384 even though SHA2-256
might do.  Of course the story may be different on 32-bit CPUs.

-- 
	Viktor.