Re: [Cfrg] Requirements for elliptic curves with a view towards constrained devices

[Watson Ladd <[e-mail]>]

On Fri, Nov 21, 2014 at 4:51 AM, Lochter, Manfred
<[e-mail]> wrote:
>
>
>
>
>
> __________ ursprüngliche Nachricht __________
>
> Von:            Watson Ladd <[e-mail]>
> Datum:  Donnerstag, 20. November 2014, 16:21:50
> An:             "Lochter, Manfred" <[e-mail]>
> Kopie:  "[e-mail]" <[e-mail]>
> Betr.:  Re: [Cfrg] Requirements for elliptic curves with a view towards
> constrained devices
>
>> On Thu, Nov 20, 2014 at 12:01 AM, Lochter, Manfred
>>
>> <[e-mail]> wrote:
>> >> Of course, you don't need to take my word for it: Cloudflare was very
>> >> clear that widespread ECDSA support was essential to making TLS free.
>> >> Mobile devices are having issues with verification times for NIST
>> >> P384. V2V proposals involves a staggering number of verifications a
>> >> second, but oddly enough don't use batching or efficient signatures,
>> >> thus forcing larger, more expensive hardware.
>> >
>> > Is there really a requirement for mobile devices to use a 384 bit curve?
>> > Why is 256 not sufficient? In which scenarios do you see the neccessity
>> > to use P-384? Which specific mobile devices are having issues with
>> > verification times? Are they having these problems only in connection
>> > with the proposed protocols you mention?
>>
>> When my mobile phone's browser connects to a website whose certificate
>> is signed by P384, a P384 verification better take place. Not
>> supporting P384 introduces an interoperability problem.
>
> I'm glad that you agree with my previously stated position that 384-bit curves
> are needed. Following your reasoning 256/384/512(521) bit curves have to be
> supported. In this case I would rather see performance problems on the
> 512/521 end.
> I would very much appreciate if you could also answer my other questions
> above.
> You seem to say that car-to-car communication will use the curves proposed by
> the cfrg. This supports the inital position we took in the Brainpool position
> paper (eprint 832/2014). I'm glad that we seem to agree on that.

The V2V projects aren't. Despite high performance constraints they are
not making optimal choices. Batch signatures would seem a natural fit,
and yet ECDSA is still being used. P256 seems to be selected, despite
Koblitz curves existing. But blinding won't be used: the performance
hit is too much, and the security model doesn't require it. It doesn't
seem like they will switch to Curve25519 if the CFRG recommends it.

Performance problems don't show up where you want them to. Any time
the fastest implementation isn't fast enough, there is a performance
problem. I don't see why users who want to use more secure curves
wouldn't care about performance, or why users who care about
performance wouldn't want the option to use larger curves. I also
don't see why random primes are good from a security perspective: they
permit a smaller multiplier, but the speed advantage of a nonrandom
curve permits a much bigger multiplier at the same cost.

Users don't care if we give them extra security. They do care if their
performance requirements aren't met by curves with adequate security,
or vice versa.

The Brainpool position paper equates hardware with high-assurance
hardware designed to resist side channel attacks, arguing that because
we can't write echo servers correctly, more people will put keys in
hardware. But this doesn't mean they need to resist side channel
attacks with large amounts of physical access to the hardware, and
certainly doesn't mean they are willing to suffer a massive
performance loss for that benefit.

Most of the applications which Brainpool inexplicably calls "hardware"
aren't. They use off the shelf microcontrollers, which don't have
bignum acceleration, and likely can't make it faster than built in
arithmetic. (There is nothing magical about doing the same
computations in a hard-coded circuit). They are much closer to
yesterday's software. This includes several "HSMs".

Sincerely,
Watson Ladd