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

From: Björn Edström <[email-masked]>
Date: Wed, 9 Dec 2015 02:40:12 +0100

For the vote [1] I'm thinking about the twoshakes-d proposal [2] and I
can't decide what to vote on it. I'd like to talk this over because it
touches some larger questions.

1) Ed25519 and Ed448 are described in the same draft. We see them as
being part of a "family" of constructs that share certain properties
or behavior with each other. They are quite similar after all. For
some definition of "related", the authors consider the constructs
related enough to be grouped together in one I.D.

Here's the subtle part. Do we see the relation as being in "shape and
form" or do we see the relation as "solving a common signing problem
at different strength levels"?

If we take the former view, then in my opinion we can't practically go
for twoshakes-d, since that will change the shape and form of Ed448 to
differ significantly from Ed25519 (which we really shouldn't touch too
much in this regard since it's already deployed widely).

If we take the latter view, then we can do whatever we want with
Ed448, as long as it's not very unreasonable, and if it is done in the
spirit of improving the strength level (which is already quite spinal
tap-grade). In this view of the world twoshakes-d is pretty fine,
since domain separation has security benefits.

--

2) Do we see HashEdDSA (such as Ed448ph) as a "signing construct with
IUF" in it's own right i.e. a different beast, or do we see HashEdDSA
as a recommendation for what hash the user will plug in into PureEdDSA
to get IUF?

The draft as is *could* have been written as "To get IUF behavior with
Ed448 an implementation SHOULD use <hash>" (i,e. skipping the entire
definition of HashEdDSA and the *ph versions) but since the *ph
versions are defined and named that implies a black box signing
construct view, from the point of view of the user (in my crypto
library I have 4 primitives instead of 2).

If we take the view that Ed448ph is a "signing construct" black box on
it's own, then the twoshakes-d proposal is fine. The black box will
take care of initializing the pre-hash for the user and the internals
are hidden.

If we take the view that Ed448ph is just a recommendation that for IUF
you should do Ed448(SHAKE(prefix||...)), which is likely what is gonna
happen in practice in actual source code, then we are in murkier
waters and have a slight preference against twoshakes-d for two minor
reasons: a) implementation errors, i.e. missing to take the prefix
into account and 2) coupling. With "coupling" I mean that the
signature context (which is seen as a different thing than the hashing
context) must now live slightly longer and is more spread out,
depending on protocol design.

Thoughts?

Cheers
Björn

[1] Poll: hash functions for Ed448 (ends on December 22nd)
[2] http://www.ietf.org/mail-archive/web/cfrg/current/msg07629.html

---

From: Bryan A Ford <[email-masked]>
Date: Wed, 9 Dec 2015 09:48:16 +0100

> at different strength levels"?

Can you clarify what you mean by "shape and form"?  e.g., do you mean
the functional property of implementing domain separation, or do you
mean the addition of the optional 'context' input to the API, or
something else (or all of the above)?

If having domain separation in Ed448 but not in Ed25519 bothers you,
then keep in mind that we could readily "back-port" the domain
separation from Ed448 to Ed25519.  That would both ensure that the same
domain-separation functionality is available for both and keep them more
closely aligned in terms of what I assume you mean by "shape and form."
 I think we should probably defer that actual discussion and decision
until later, e.g., until a group consensus emerges whether the domain
separation is a good idea for Ed448 in the first place - but for now we
can at least keep in mind that it's an option.  See my earlier E-mail
exploring three different possible "backporting" approaches:

	http://www.ietf.org/mail-archive/web/cfrg/current/msg07643.html

With due deference to the IETF's traditional position of "not specifying
APIs", my working assumption in proposing twoshakes-d was that both
HashEdDSA and PureEdDSA were both going to be considered "first-class"
signing schemes with appropriate "first-class" entrypoints in relevant
APIs.  That is, I assume a mature EdDSA API (whether for Ed25519 or
Ed448) would/should include at least some minimal support functions to
help the client compute prehashes properly according to the specification.

For example, in APIs that have a generic Hash
interface/abstract-base-class of some kind, the signing API for both
Ed25519 and Ed448 might look something like (in pseudocode):

scheme.PureSign(message []byte) -> []byte signature

scheme.Prehash() -> Hash object with standard IUF interface
scheme.HashSign(Hash object) -> []byte signature

Even if Ed448 does domain-separation and Ed25519 doesn't (i.e., no
backporting of domain-separation mechanism), the API can still look
exactly the same for the two schemes: it's just that ed448.Prehash()
will create/initialize the Hash object and Write the domain-separation
prefix to it, whereas ed25519.Prehash() will just create/initialize the
Hash object without writing anything to it.  The client using the API
need be none the wiser.

Cheers
Bryan