Re: [Cfrg] FourQ draft now available

[Hanno Böck <[e-mail]>]

Hi,

On Thu, 22 Sep 2016 07:05:31 -0700
Watson Ladd <[e-mail]> wrote:

> We would like to announce draft-ladd-cfrg-4q-00, which presents a
> high-speed Diffie-Hellman key agreement based on the elliptic curve
> FourQ. 
[...]
> We hope this draft sees its way to an RFC soon.

I wonder if this is something that should really happen.

Having more choices of cryptographic constructions is imho not always
good. It has a cost: More code, more complexity, more stuff to analyze.
Therefore each new cryptographic primitive that gets introduced needs a
good justification. I'm not sure I see this here.

We just introduced curve25519/448 and many people are moving to them.
In the more or less far future we'll probably see movements to some kind
post quantum cryptography. So I only see a relatively small time window
where this curve will be used, therefore I'd like to see more
justification why we should standardize it.

From what I see the major advantage is that FourQ is supposed to be
faster than curve25519. On the flipside I see this:

   Implementations MUST check that input points properly decompress to
   points on the curve.  Removing such checks may result in extremely
   effective attacks.  The curve is not twist-secure: implementations
   using single coordinate ladders MUST validate points before operating
   on them.

From my limited understanding of ecc security this means we introduce a
new elliptic curve which is faster than curve25519, but much more prone
to implementation security flaws.

I'm not saying I'm strictly against standardizing this, but if it's
going to happen I'd like to see better justifications. Where do you see
that curve being used? Are there scenarios where the performance
improvements matter, as in "we would like to add crypto to X, but
curve25519-based crypto just isn't fast enough"? Do you see this
realistically to be used in TLS or other major protocols? Are there
other people on this list that have concrete plans to implement this in
their product/protocol?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [e-mail]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42