Re: [Cfrg] On the differences of Ed25519/448 and how it affects a vote on twoshakes-d

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 18 December 2015 20:23 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851BA1B37AE for <cfrg@ietfa.amsl.com>; Fri, 18 Dec 2015 12:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level:
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] 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 yNmDpchMGOu2 for <cfrg@ietfa.amsl.com>; Fri, 18 Dec 2015 12:23:14 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id E5CEE1A8957 for <cfrg@irtf.org>; Fri, 18 Dec 2015 12:23:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 7DA949C; Fri, 18 Dec 2015 22:23:11 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id BNs0Gzt8Vh_e; Fri, 18 Dec 2015 22:23:11 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 034E82319; Fri, 18 Dec 2015 22:23:11 +0200 (EET)
Date: Fri, 18 Dec 2015 22:23:07 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Gilles Van Assche <gilles.vanassche@st.com>
Message-ID: <20151218202306.GA21472@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAA4PzX18bcS_awPg-YDAoo90537Ot=s_nf7k_Vt75OVSdvtDrQ@mail.gmail.com> <87fuzcng51.fsf@latte.josefsson.org> <20151209125944.GA26766@LK-Perkele-V2.elisa-laajakaista.fi> <566AEB08.9070302@st.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <566AEB08.9070302@st.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/cvAlKU1SP8OZ2u2OSZjPQsFp_Jk>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] On the differences of Ed25519/448 and how it affects a vote on twoshakes-d
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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: Fri, 18 Dec 2015 20:23:16 -0000

On Fri, Dec 11, 2015 at 04:26:00PM +0100, Gilles Van Assche wrote:
> 
> With the point of view above, there is no problem if a public key is
> used in either Ed448 or Ed448ph. This follows from that if f(x) is a
> sound hash function, then so is f(dom|x) for a fixed prefix "dom".
> 
> With a public key used for both Ed448 and Ed448ph, the internal hash can
> be viewed as a tree-hash mode on top of SHAKE256, such as:
>     without pre-hashing:
>         H(x|M)=SHAKE256(dom00|x|M), or
>     with pre-hashing:
>         H(x|M)=SHAKE256(dom10|x|SHAKE256(dom11|M)),
> where "domXY" follows Bryan's coding with X separating between PureEdDSA
> and HashEdDSA and Y separating between the internal hash and the
> prehash. The security of this domain separation scheme follows from
> checking the sufficient conditions defined in [1].

Seperating between internal hash and prehash is not needed. One can
show that even without prehash prefix any forgery either yields forgery
on the base scheme or is prehash collision. And absolutely no security
is promised in either of those cases.

Furthermore, unless one wants to do random prefixes (which greatly
strengthen signatures), one presumably does not want to deal with
any sorts of prefixes on hashes (and postfixes are pointless),
which tend to force having to calculate hashes multiple times, but
take raw hash value to sign.

OpenPGP works that way. TLS is impiled to work that way. SSH does not
need IUF. Etc...


-Ilari