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

[Simon Josefsson <[e-mail]>]

Ilari Liusvaara <[e-mail]> writes:

> On Sat, Dec 12, 2015 at 01:14:00PM +0100, Bryan Ford wrote:
>> On Dec 12, 2015, at 12:14 PM, Ilari Liusvaara
>> <[e-mail]> wrote:
>> > This brings to mind the following (bit crazy):
>> > 
>> > - Leave Ed25519 as is.
>> > - Drop Ed25519ph
>> > - Add Ed25519dom, with context and hash-signing capabilities.
>> > - Drop Ed448ph
>> > - Rename Ed448 to Ed448dom, with context and hash-signing capabilties.
>> 
>> This seems like a potentially pretty reasonable "sweet spot"
>> compromise between the semi-conflicting goals of (a) domain
>> separation, (b) alignment between Ed448 and Ed25519, and (c)
>> backward compatibility with current Ed25529 uses without prehashing
>> or domain separation.
>> 
>> The one downside I see is that "pure" Ed25519 wouldn't be domain-
>> separated from ed25519dom, i.e., signatures generated with the former
>> could in principle get misinterpreted as the latter and vice versa.
>> But this is probably a small risk we can live with for backward-
>> compatibility reasons. 
>
> Those two would be separated at key level (like Ed25519 and Ed25519ph
> are currently).

Right.

One concern is that approaches like Ed25519ph are already deployed,
compared how Ed25519 is used in OpenPGP.

So a proposal for moving forward could be:

* Leave Ed25519 and Ed25519ph as is and publish now

* Specify Ed448 with twoshakes-d ("Ed448dom") and have it in draft form
  until some implementation experience with it develops

I think we are seeing effects of different level of interest between
Ed25519 and Ed448 coming to a closure here: the Ed25519(ph) effort is
about documenting something that is already out there, while Ed448(dom)
is about describing something new that is not deployed.  While it is
nice to have these in the same document, I feel more and more that this
is problematic.  But we'll have to see what the outcome of the current
poll is first.

/Simon