Re: [Cfrg] Finishing Ed448 definition

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 28 November 2015 13:35 UTC

Date: Sat, 28 Nov 2015 15:35:47 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20151128133547.GA5652@LK-Perkele-V2.elisa-laajakaista.fi>
References: <56508C20.7090009@isode.com> <565109E4.7000904@gmail.com> <5655E8F3.8050404@st.com> <87io4pxhkn.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <87io4pxhkn.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/-15n03A6rc-_y97UmPsK-oKnWPQ>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Finishing Ed448 definition
Precedence: list

On Thu, Nov 26, 2015 at 09:58:48AM +0100, Simon Josefsson 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.
> 
> So for me, at this point, I would prefer twoshake-s, or both my other
> proposals (SHAKE256+SHA3-512 and SHA2-512/912+SHA2-512), over
> twoshakes-d.

Agreed (Through I think SHA3-512 isn't good).

Two other proposals:

1)

Hash: SHAKE256@912bits(x)
Prehash: SHA2-512(x)
Brief rationale: The Same prehash for both Ed25519ph and Ed448ph
	might be useful if some application wants to prehash the
	data[1]. Also, SHA-512 is one of the fastest unbroken hash
	functions around (pretty much only Blake2 is faster)[2].


2) From Alex Elsayed (with constraints given[2] fully propagated)

Hash: HKDF-EXPAND(hash=SHA2-512, prk=HKDF-EXTRACT(hash=SHA2-512,
	salt=<blank>, ikm=x), info=<blank>, 114)
Prehash: SHA2-512(x)
Brief rationale: The purpose calls for a KDF, and HKDF is the
	standard KDF. It is broadly implenmented, including in
	hardware, single-wide so doesn't require twice the work,
	not new unlike SHAKE and designed for arbitrary-length
	outputs.


[1] Not that I think this kind of operation is desriable, but...

[2] SHAKE256 is a bit slower than SHA-512. I think SHA3-512 is
hilariously slow (SHA-512 is like 2-3x the speed).

[3]
1) Salt does not contain key material
2) Info does not contain message.
3) (I added this): Collisions can't be trivially exploited.

Propagating the constraints yields that everything must
go into IKM, as anything else would break at least one
of the constraints.


-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