Re: [Cfrg] FourQ draft now available

[David Jacobson <[e-mail]>]

On 9/24/16 2:58 AM, Hanno Böck wrote:
> On Fri, 23 Sep 2016 09:46:25 -0700
> Watson Ladd <[e-mail]> wrote:
>
>> 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.
> I can understand the Apple use case, however I wonder if this is really
> an issue, would like to see numbers on that (given all the things an
> iphone does I'd assume a curve25519 operation isn't really on top of
> the things).
> I'm much more worried about your second idea - IoT. Given the
> security track record of IoT I'd rather not give them something that
> they can mess up easily. Reading the FourQ draft it explicitly says
> that it's not twist secure and that point checks have to be
> implemented. I'd rather give them something without such pitfalls, aka
> curve25519 for now.
>
>> 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.
> They are RFC'ed, but are they actually used?
> This is actually more an example of the bloat things I'd like to avoid:
> People put crypto in RFCs because of national pride ("we need our
> German elliptic curves" - seriously, I heard that multiple times), not
> because of technical arguments.
>
> The FourQ case is different - there is a technical argument (speed),
> but I still wonder if that's good enough to justify an RFC.
>
I used to work in the mobile device industry.  For a long time most 
mobile devices used 2048 bit RSA with exponent 3 because it was the 
fastest thing available to verify a signature.   Security conscious 
companies adopted 2048 bit RSA with exponent 65537 for added safety.   
So I suggest that these are the reference points for deciding whether 
FourQ has a good chance of getting traction based on performance.

I find the automotive collision avoidance case quite compelling.  It 
will be challenging to verify hundreds of messages per second.

If you are worried about crypto being done in an unsafe way (for 
example, not doing necessary checks) there is a simple fix:  Supply 
working code that is safe and decently optimized.  Sometimes "reference 
code" has truly terrible performance, and is only useful as the "other 
party" in a validation setup.  (SNOW 3G is a prime example.)

To facilitate adoption, make it easy for developers to get this 
algorithm approved by their legal department.
1.  Do whatever you can to allay fears that something might be 
patented.  Just having the basic inner algorithm unencumbered is not 
enough.  it must be the case the combination of the optimized inner 
algorithm as actually implemented and all the checks required for 
safety, i.e. everything in that supplied code, is unencumbered.  I'm 
aware that some standards bodies are constrained in what the can do 
regarding patents.  But do what you can, perhaps working outside any 
standards body.
2.  Release the code under a generous minimally-constraining license 
(e.g. BSD), or put it in the public domain.

    --David Jacobson