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

[Björn Edström <[e-mail]>]

Hi cfrg,

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