Re: [Cfrg] Message Digest Algorithm Choice for CMS with Ed448

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 16 November 2016 08:31 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793251296AC for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2016 00:31:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=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 v-oY5aMEDwsc for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2016 00:31:44 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 80C22129634 for <cfrg@irtf.org>; Wed, 16 Nov 2016 00:31:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 2A014111CF; Wed, 16 Nov 2016 10:31:42 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id fCtvG2aFCic6; Wed, 16 Nov 2016 10:31:41 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DBF9721C; Wed, 16 Nov 2016 10:31:41 +0200 (EET)
Date: Wed, 16 Nov 2016 10:31:37 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Russ Housley <housley@vigilsec.com>
Message-ID: <20161116083137.GA8403@LK-Perkele-V2.elisa-laajakaista.fi>
References: <7DDD1353-96FC-4E70-8427-AA9C6F499232@vigilsec.com> <E07E9956-F0E9-4992-917C-8DA96CDE8252@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E07E9956-F0E9-4992-917C-8DA96CDE8252@vigilsec.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Se0R2MnpHhmrTGi1o_LeIXlAVCQ>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Message Digest Algorithm Choice for CMS with Ed448
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 08:31:46 -0000

On Wed, Nov 16, 2016 at 02:22:24AM -0500, Russ Housley wrote:
> I’d like to summarize what I have heard.  Either SHA3-512 or
> SHAKE256-512 provide the necessary protection.  Both of these
> use Keccak, and both produce a 512-bit result.  SHAKE256 is
> more efficient.
> 
> I wrote a small test program, and it confirms that SHAKE256
> is more efficient than SHA3-512.

Note that from theoretical grounds, one gets that SHAKE256 is supposed
to have 89% higher throughput than SHA3-512 (or equivalently hashing
takes 47% less time) over long messages.

This if from the fact that SHAKE256 packs 136 data octets into each
block, whereas SHA3-512 only packs 72. And the algorithm to process
each block is the same. So SHAKE256 processes about 136 octets in the
same time as SHA3-512 processes 72.

The security level difference is in preimage resistance (512->256
bits), but 256 bit security level is more than sufficient here,
given that the curve is weaker than that.

Output length adjustment to "match security levels" is not helpful,
given that the block counts will be the same anyway.

Also, I hope that there is some envelope around the raw SHAKE256
result. Otherwise the result is the same as Ed448ph, except without
the TBS collision protection w.r.t. Ed448.


-Ilari