Subject: Re: [Cfrg] Ed448ctx -> was RE: draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 19 Jul 2016 20:41:35 +0300

On Fri, May 06, 2016 at 09:21:50AM +0200, Simon Josefsson wrote:
> Paul Lambert <[email-masked]> writes:
> 
> >> > On Sat 2016-04-23 03:23:15 -0400, Simon Josefsson wrote:
> >> >> Further, introducing this tweak late in the process appears unfortunate.
> >> >> We are having serious trouble shipping documents people have been
> >> >> waiting for as it is.  Redefining what they will get this late in the
> >> >> process is harmful.
> >> >
> >> > My goal in raising this is not to delay the process further, but to at
> >> > least clarify for future readers why the interfaces for Ed25519 and
> >> > Ed448 differ by a "context" argument, and to give some form of
> >> > implementation guidance to people who want to use that argument while
> >> > being able to use both signature schemes.
> >
> > Making names clear is a good idea.
> > Perhaps Ed448 should be renamed Ed448ctx
> 
> I like this idea -- there is confusion between the "old" Ed448 and
> CFRG's modified Ed448 with contexts.  It is pretty mild since the old
> Ed448 has not been widely deployed, but still.  If someone like to push
> for this, I would support it.

One way to solve things would be to restrict the Ed448 context to non-
empty strings and name the result to "Ed448ctx" and take currying
of current Ed448 with empty context string and name it as "Ed448".

And then perhaps apply analogous construct to Ed25519 to derive
Ed25519ctx and to switch Ed25519ph to that sort of construct.

Of course, this doesn't solve the problems with the *PH variants:
- Ed25519ph can be confused with Ed25519 with bad results (the new
  construction would probably solve that).
- Ed448ph still has contexts, which is made practicularly hilarious by
  the fact that *ph variants were originally included because of
  legacy APIs (at least going by the rationales), which probably aren't
  going to take contexts very well... And if Ed25519ph is switched to
  that new construct, it would get this problem as well...

-Ilari