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

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 13 November 2016 06:13 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 9ADDE1295EC for <cfrg@ietfa.amsl.com>; Sat, 12 Nov 2016 22:13:12 -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 4-mBGvnlIbqK for <cfrg@ietfa.amsl.com>; Sat, 12 Nov 2016 22:13:10 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 928AC1294B4 for <cfrg@irtf.org>; Sat, 12 Nov 2016 22:13:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 184DE12C5F; Sun, 13 Nov 2016 08:13:08 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fbXKmhzMtD3R; Sun, 13 Nov 2016 08:13:07 +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 C0BAB21C; Sun, 13 Nov 2016 08:13:07 +0200 (EET)
Date: Sun, 13 Nov 2016 08:13:03 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Message-ID: <20161113061303.GA3000@LK-Perkele-V2.elisa-laajakaista.fi>
References: <7DDD1353-96FC-4E70-8427-AA9C6F499232@vigilsec.com> <683700509df04d2eb8874fd292462946@XCH-RTP-006.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <683700509df04d2eb8874fd292462946@XCH-RTP-006.cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/rTyIZ6Yfb-h3x1Wi7ipO8WaxGmI>
Cc: IRTF CFRG <cfrg@irtf.org>, Russ Housley <housley@vigilsec.com>
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: Sun, 13 Nov 2016 06:13:12 -0000

On Sun, Nov 13, 2016 at 04:20:28AM +0000, Scott Fluhrer (sfluhrer) wrote:
> 
> > -----Original Message-----
> > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley
> > Sent: Saturday, November 12, 2016 10:55 PM
> > To: IRTF CFRG
> > Subject: [Cfrg] Message Digest Algorithm Choice for CMS with Ed448

> > What message digest algorithm should be used in step 1?
> > 
> > It seems that SHA3-512 would be a good choice to avoid having to implement
> > more that one message digest algorithm to generate the signature or
> > validate it.
> 
> How about SHAKE256, with the output limited to 256 bits?  SHAKE256 in
> that mode ought to have the same security properties as SHA3-256 (as
> they are the same except for different end-message padding).

Eeh... Except SHAKE256 has 256-bit collision resistance, so one needs
512-bit output to reach that bound. And this is signatures right, where
collision resistance is the most important?

The preimage resistances cap at 256 bits, but those aren't that
important with signatures, and 256 bits is above the security level of
the curve anyway.

So 512-bit output?


-Ilari