Re: [Cfrg] Curve manipulation, revisited

[Tony Arcieri <[e-mail]>]

On Sun, Dec 28, 2014 at 11:57 PM, Benjamin Black <[e-mail]> wrote:

> The request might've come from the TLS-WG, but it is almost inconceivable
> that something CFRG recommended to TLS-WG would not be quickly adopted by
> many other WGs. It is disingenuous to argue that since the request came
> from TLS-WG nothing outside TLS-WG should be a consideration while also
> arguing that things like cofactors for 1 (mod 4)  curves must be exactly
> (8,4) without giving an example of how it matters to TLS-WG. The latter is
> an implicit acknowledgement that the scope extends beyond TLS-WG.
> Similarly, suggesting that TLS-WG could be given only X25519 without
> Ed25519 being pulled in is either naive or an attempt to sneak them both in
> the back door.
>

I think you can avoid this slippery slope by the CFRG recommending
Curve25519 as one of potentially many curves at a 128-bit security level,
for now, as an interim solution, simply to avoid the current situation of
apparent infinite deadlock.

Proposal: If and when rigid curve generation guidelines can be agreed upon,
the CFRG can recommend an "updated" curve at a 128-bit security level.

Everything I've described is little different from exactly what's happening
right now: there's an informal agreement on Curve25519, and you would like
to specify a different curve based on "rigid" guidelines.

I'm afraid if we wait on the bikeshedding debate surrounding what
constitutes "rigidity" to conclude, we're just going to be stuck with the
existing choices forever.

Compromise to avoid the slippery slope: proceed with Curve25519 for D-H
with an option for a new curve in the future after the rigidity
bikeshedding debate is over, and postpone any Ed25519-related discussion
until after that.

Here in the real world we're still using RSA signatures. I don't know how
many years until the stuff being discussed here actually trickles down into
what I can practically use day-to-day.

-- 
Tony Arcieri