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

[Watson Ladd <[e-mail]>]

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 have never seen an adequate explanation of why p random is needed
>> for security. What I have seen is an explanation of particular
>> blinding measures that only work with p random. But there are blinding
>> measures that don't depend on random p, that are more efficient.
>> Furthermore, if hardware already deals with the NIST curves, it has to
>> deal with nonrandom p already.
>
> Which specific more efficient blinding measures are you addressing? Could you
> provide sources?
> What does efficient mean for these countermeasures? A better protection
> against SCA or higher speed? Or lower cost?
> How is the patent situation for theses countermeasures?

Most devices randomizing exponents compute xP as [aq+x]P where a is
some random number and q is the order. Random primes apparently permit
q, and thus aq+x to be smaller. But each arithmetic operation, and
thus each point addition or doubling, is twice as fast for a special
prime, and thus a can be the size of q, and we have equal performance
to an unblinded multiplication on a random prime curve. This is better
protection and it's faster. It's identical to the protection you
described, except we've increased the size of a.

This was described by DJB in an email to the list, titled "Primes vs.
hardware side channels", sent October 16th.

Of course, one can always continue to use brainpool. I don't see why
the new curves have to force a 50% slowdown on everyone for benefit of
a very restricted, largely unused class of devices.

Sincerelu.
Watson Ladd

>
> Manfred
>
>>
>> Sincerely,
>> Watson Ladd
>>
>> > [1]
>> > https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottlen
>> >eck/
>> >
>> > [2] https://eprint.iacr.org/2014/130.pdf
>> >
>> > [3] http://www.statisticbrain.com/google-searches/
>> >
>> > [4] Zero-Value Point Attacks :
>> > https://www-old.cdc.informatik.tu-darmstadt.de/reports/TR/TI-03-01.zvp.pd
>> >f
>> >
>> >
>> >
>> > Franck RONDEPIERRE
>> >
>> > Oberthur Technologies
>> >
>> > Technology & Innovation , R&D Cryptography Engineer
>> >
>> > 420 rue d'Estienne d'Orves | 92700 Colombes | France
>> >
>> > Phone: [phone]   | Fax : [phone]
>> >
>> > E-mail : [e-mail] | Web : www.oberthur.com
>> >
>> > P Please consider your Environmental Responsibility: Before printing this
>> > e-mail or any other document, ask yourself if you need a hard copy
>> >
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> > [e-mail]
>> > http://www.irtf.org/mailman/listinfo/cfrg
>
> --
> Lochter, Manfred
> --------------------------------------------
> Bundesamt für Sicherheit in der Informationstechnik (BSI)
> Referat K21
> Godesberger Allee 185 -189
> 53175 Bonn
>
> Postfach 20 03 63
> 53133 Bonn
>
> Telefon: [phone] 5643
> Telefax: [phone] 5643
> E-Mail: [e-mail]
> Internet:
> www.bsi.bund.de
> www.bsi-fuer-buerger.de



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin