Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master

[Andrey Jivsov <[e-mail]>]

On Oct 8, 2014 11:52 PM, "Mike Hamburg" <[e-mail]> wrote:
>
>
> On 10/8/2014 10:47 PM, Andrey Jivsov wrote:
>>
>>
>> Montgomery curve has fewer underlying filed operations. The performance
benefit will be lower than due to prime reduction/hardware/instruction
assistance. However, given that the numbers are fairly close now, we can
expect change in leadership depending on the mix of features. For example,
a hypothetical mix of the P-256 underlying field operations found in the
code that I timed and a Montgomery curve on top would probably move such an
implementation into the lead in the tests I performed.
>
> Yeah, or getting Shay and Vlad to hand-tune an x25519 implementation :-)

BTW, I may be wrong on this one, but the latest performance boost I
reported yesterday is due to OpenSSL team, I believe.

>
>> P-256 has an advantage that it's in standards, widely deployed, can do
point additions (without penalty of coordinate conversion), and you can get
X.509 certs with it. It would have been easier to argue on its
disadvantages if it had worse performance than it appears to have. I am
aware of other disadvantages of P-256.
>>
>> In your other e-mail, Watson, regarding AVX2/vector operations + X25519,
it's an interesting question. The issues here are:
>> * will this hide some benefits of the 2^n-1 prime?
>
> Possibly.  You probably won't be able to use Langley and Bernstein's
carry handling techniques, but fewer coefficients is always good.
>>
>> * increase code complexity?
>
> Compared to a version without handwritten asm?  The field arithmetic will
definitely be more complex.

... and the combined code not so neat ...

>
>> * it seems that this is of no use to mobile devices (in the near future
anyway)
>
> Curve25519 performs quite well on ARM NEON.

My list is regarding vector operations. I was alluding that one of the
driving forces for new ECC is its excellent performance on mobile devices
but many of them don't have vector athithetic. Therefore, there is no
immediate ownership apparent of such vectorized code (until it is in
OpenSSL :-)).

>
>> * but servers will benefit from this.
>
>
> Cheers,
> -- Mike