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

[Ilari Liusvaara <[e-mail]>]

On Wed, Dec 09, 2015 at 10:08:26AM +0100, Simon Josefsson wrote:
> 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.

Yeah, algorithm that prehashes internally is quite different from one
that takes the prehash as parameter.

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

I also don't feel comfortable with it. I think there are two main issues
with it, one is easy to fix and the other is hard to fix:

- The easy-to-fix one: I think instead of simple prehashed/not flag,
  one should have indication of prehash algorithm. Different protocols
  have different preferences there, and also the likelyhood of the
  prehash breaking seems immensely greater than the main hash.

  There is precendent for this kind of operation: PKCS#1 v1.5 RSA
  signatures try to perform hash separation (but fail at it, for
  reasons unrelated to the interface).

  This also comes up in practice: E.g. Adding PureEdDSA to TLS is
  very simple conceptually: Have curve for each scheme (there are
  64,000+ curve IDs free, so not running out) and use the reserved-
  for-future none hash. Then HashEdDSA is completely different matter,
  with interactions being much murkier (due to fixed prehash, which
  might not even have existing choice).

- The hard-to-fix one: Contexts. While cute idea and very useful for
  blocking cross-protocol attacks that are so darn hard to block any
  other way, the interface parts are concerning.

  It is not just plumbing the context into the API of the library
  handling signatures. It is also plumbing the context into interface
  of all sorts of frameworks different protocols use (that don't
  support contexts of their own), and there are quite many of these.

  Also, for any protocol to take the option of using contexts, the
  contexts must be reliably available (especially with hacks like
  how contexts were added to Ed25519-like scheme).



-Ilari