<p dir="ltr"></p>
<p dir="ltr">On Mon, Jan 19, 2015 at 8:26 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br>
> On Mon, Jan 19, 2015 at 5:03 PM, D. J. Bernstein <<a href="mailto:djb@cr.yp.to">djb@cr.yp.to</a>> wrote:<br>
>> <a href="http://bench.cr.yp.to/impl-scalarmult/curve25519.html">http://bench.cr.yp.to/impl-scalarmult/curve25519.html</a> compares speeds of<br>
>> various Curve25519 implementations on various platforms. Longa was<br>
>> presenting a small extract from this data.<br>
>><br>
>> For "64-bit" platforms the best non-vectorized radix is sometimes 2^64,<br>
>> sometimes 2^51, for reasons explained in the Ed25519 paper. Vectorized<br>
>> speed records---e.g., speed records on typical smartphones---typically<br>
>> use radix 2^25.5.<br>
>><br>
>> Longa seemed to be trying to mislead people into believing that this<br>
>> platform variation in _implementation_ techniques creates a platform<br>
>> variation in _prime_ choices. It should be obvious that these data<br>
>> points say nothing about prime choice: they're all for one prime.<br>
><br>
> You're disputing his Slide 9 I think ("Comparison of x64<br>
> implementations Unsaturated versus Saturated"). That slide may be<br>
> simplistic, but his overall point seems correct that platform<br>
> variation in implementation techniques might favor different primes.<br>
><br>
> It seems like you and Mike agree that full-radix might be more<br>
> efficient on some platforms.<br>
><br>
> It also seems true that some primes will be more or less efficient in<br>
> a full-radix implementation, For example, I would think primes that<br>
> slightly spill over into the next word are less efficient in<br>
> full-radix (like 2^389-21, or 2^2521-1).</p>
<p dir="ltr">This would seem to me its the only effect if we use Barrett reduction. Or am I not understanding the algorithms used in the full radix case?</p>
<p dir="ltr">In particular, the reason I picked 2^389-21 was the complaints about dropping security below 384. But now it seems we can go down much lower: it may be that 2^379-19 is the best choice in exponents from 352 to 384. But my guess is all these other primes have the same speed on full radix implementations. </p>
<p dir="ltr">Of course, users care what the fastest implementation on a CPU is, not whether it uses full or reduced radix.</p>
<p dir="ltr">><br>
> So his argument that we should consider full-radix when choosing<br>
> performance-oriented primes seems reasonable to me. Seems like we<br>
> should try to get more analysis and timings for full-radix Ted37919,<br>
> Curve41417, Goldilocks, E-521, etc.<br>
><br>
><br>
>> A closer study of implementation techniques shows that choosing mediocre<br>
>> primes such as 2^256-189<br>
><br>
> He was using this argument for 2^379-19, not 2^256-189. Obviously<br>
> 2^256-189 was chosen based on different criteria, with less emphasis<br>
> on performance.<br>
><br>
><br>
>> In other words, switching to mediocre primes hurts some platforms and<br>
>> doesn't help others. To avoid seeing this damage, one has to ignore all<br>
>> the reduced-radix implementations and ignore all the platforms where<br>
>> those implementations are best---and even within these blinders there's<br>
>> no advantage to the mediocre primes. Not A Tough Decision(tm).<br>
>><br>
>> I'm not saying that at _every_ security level there's a unique standout<br>
>> cross-platform prime; I'm just saying that Longa wasn't looking at the<br>
>> right data for the decision that he claimed to be interested in.<br>
>><br>
>>> 2) Full-radix may be safer and easier to implement, since<br>
>>> reduced-radix requires "Bound analysis" to prevent inadvertent word<br>
>>> spilling, thus is "error prone, errors are more difficult to catch".<br>
>><br>
>> There's a long history of hard-to-catch errors in full-radix software.<br>
>> <a href="https://cryptojedi.org/papers/#verify25519">https://cryptojedi.org/papers/#verify25519</a> is the first step towards<br>
>> confidently getting out of this mess---and it's significantly _easier_<br>
>> for reduced-radix software than for full-radix software.<br>
><br>
> That's interesting and not intuitive to me. I'd think reduced-radix<br>
> was trickier to implement and analyze. Huh...<br>
><br>
> Trevor<br>
> _______________________________________________<br>
> Curves mailing list<br>
> <a href="mailto:Curves@moderncrypto.org">Curves@moderncrypto.org</a><br>
> <a href="https://moderncrypto.org/mailman/listinfo/curves">https://moderncrypto.org/mailman/listinfo/curves</a><br><br></p>
<p dir="ltr">--<br>
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety."<br>
-- Benjamin Franklin</p>