Re: [Cfrg] FourQ draft now available

On Thu, Sep 22, 2016 at 11:49 PM, Hanno Böck <hanno@hboeck.de> wrote:
> Hi,
>
> On Thu, 22 Sep 2016 07:05:31 -0700
> Watson Ladd <watsonbladd@gmail.com> 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.

If you don't want to support it, don't do so.

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

One of the high-profile uses of Curve25519 is in locking the disk of an
iPhone (do we have a flash compatible term for that yet). This requires a
public key operation on the receipt of any push message, which directly
impacts battery life. With IoT many more devices will have quiescent
states, until an event happens which they need to quickly process.

Realistically it could be used in TLS. Plenty of little known national
curves are. But I think a lot of applications are more demanding then TLS
on crypto performance.

>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.