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

[Simon Josefsson <[e-mail]>]

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

> 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.

If we select twoshakes-d, I believe we should consider separating
Ed25519(ph) and Ed448 into two documents.  While sharing some elements,
they have become different beasts.  Ed25519(ph) is domain separated by
naming, Ed448 will be domain separated by parameters.  The separate
algorithm Ed448ph no longer makes any sense; whether to prehash or not
becomes a parameter to the process instead.

If the twoshakes-d domain separation is a good domain separation
algorithm or not is something I don't feel qualified to judge, but I
don't feel comfortable with it as it is novel.  The algorithms will
behave different and have different security considerations.

> 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).

I agree with this, and share this line of thinking.

> 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.

Sure.

> 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?

I believe the former.  The latter thinking leads to domain separation
issues when the IUF-plugin becomes optional.

> 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).

Right.  If we don't consider twoshakes-d, there would be 4 primitives.
With twoshakes-d, there could be three with the Ed448 variant taking
parameters to achieve domain separation.  Ed448(ph) with twoshakess-d
questions to point of the naming separation, and it might as well be
called just Ed448.

> 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.

I share this concern with twoshakes-d.

/Simon

> 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
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg