Re: [Cfrg] Finishing Ed448 definition

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

Date: Fri, 11 Dec 2015 22:22:14 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Bryan Ford <brynosaurus@gmail.com>
Message-ID: <20151211202214.GA5522@LK-Perkele-V2.elisa-laajakaista.fi>
References: <56508C20.7090009@isode.com> <565109E4.7000904@gmail.com> <5655E8F3.8050404@st.com> <87io4pxhkn.fsf@latte.josefsson.org> <32FEDB05-C70E-47EE-A6C3-7FFA982F9BF6@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <32FEDB05-C70E-47EE-A6C3-7FFA982F9BF6@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/KE9-hlfA7Ikyo-ItdMK_zveE-OU>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Finishing Ed448 definition
Precedence: list

On Thu, Nov 26, 2015 at 10:32:38AM +0100, Bryan Ford wrote:
> > On Nov 26, 2015, at 9:58 AM, Simon Josefsson <simon@josefsson.org> wrote:
> > 
> > Gilles Van Assche <gilles.vanassche@st.com> writes:
> > 
> >> Hi Bryan,
> >> 
> >> I have a preference for your second proposal "twoshakes-d", for its
> >> domain separation between PureEdDSA and HashEdDSA. This would have the
> >> practical advantage of allowing a single key to be used for both options
> >> (if certified as such), without input clashes at the internal hash level.
> > 
> > That would be nice -- but having Ed25519 and Ed448 differ this
> > significantly would appear like a strange design choice to me.
> 
> I suggest we treat the possibility of "back-porting" domain
> separation to Ed25519 as a separate discussion issue that's
> (mostly) orthogonal to what to do for Ed448 - but with that in
> mind, here are three possible back-porting approaches I considered:
> 
> 1. Direct back-port: just change the Ed25519-based spec to add the
> same 'dom' prefixes to the hash inputs in exactly the same way as
> for Ed448, with the 'SigEd448' changed appropriately to (eg)
> 'SigEd255' or 'SigEd25519'.  Advantage: domain separation features
> completely consistent across the two curves. Disadvantage: breaks
> binary signature compatibility with existing "classic" Ed25519
> signatures. 

I see breaking of backwards compatiblity as a _major_ disadvantage.
There's plenty of high-quality Ed25519 implementations out there
(unlike say for ECDSA) and one would have to modify fair amount of
things.

> 2. Back-port with silent compatibility exception: define the
> Ed25519 sig scheme to do domain separation in the same way as
> Ed448, *except* in the one special case of PureEd25529 with an
> empty context string, in which case the dom prefix becomes empty
> (no domain separation) for backward compatibility with classic
> Ed25519. Advantage: mostly consistent across curves, and backward
> compatible. Disadvantage: hokey special case, and the slight
> security risk that a use of PureEd25519 with empty context string
> being confused with a domain-separated use of Ed25519. 

That would at least allow using existing implementations. However,
there would still be practical obstacles to using the contexts.

Not that contexts would be easy to use even with primitive
designed for those from the start.

> 3. Back-port directly as in #1, so both PureEd* and HashEd*
> are always domain separsted and incompatible with classic Ed25519,
> but define an additional eg 'BareEd25519' scheme variant just for
> backward compatibility with non-domain-separsted classic Ed25519.
> Encourage all new applications/protocols to use PureEd* or BareEd*
> while defining BareEd25519 as being available for legacy
> compatibility. 

Pretty much suffers the same problems as #2.


-Ilari

[Cfrg] Finishing Ed448 definition Alexey Melnikov
Re: [Cfrg] Finishing Ed448 definition Bryan A Ford
Re: [Cfrg] Finishing Ed448 definition Gilles Van Assche
Re: [Cfrg] Finishing Ed448 definition Mike Hamburg
Re: [Cfrg] Finishing Ed448 definition Simon Josefsson
Re: [Cfrg] Finishing Ed448 definition Simon Josefsson
Re: [Cfrg] Finishing Ed448 definition Bryan Ford
Re: [Cfrg] Finishing Ed448 definition Ilari Liusvaara
Re: [Cfrg] Finishing Ed448 definition Ilari Liusvaara