Re: [Cfrg] Benchmarks: 384 vs 389 vs Goldilocks vs ... on Haswell

["Paterson, Kenny" <[e-mail]>]

Hi Watson,

Following up on a recent message that specifically asked a question to me.

On 31/12/2014 21:01, "Watson Ladd" <[e-mail]> wrote:

>On Wed, Dec 31, 2014 at 3:01 PM, Paterson, Kenny
><[e-mail]> wrote:
>> Hi Mike,
>>
>> Thanks a lot for doing this work, especially over the holiday season -
>> it's much appreciated.
>>
>> My take-away from your work is that there's no strong reason (in
>> performance terms) to prefer P389 over P384-mers or vice-versa - the
>>8-9%
>> difference is there, yes, but could easily disappear or increase with
>> further optimisations on either side.
>
>Would you say the same about 2^255-19 vs 2^256-189? That also had a 8%
>performance increase iirc, for very similar reasons.

Yes, I would. But there, we have running code and deployment in favour of
the curve Curve25519 (used in various algorithms which may or may not be
the ones we want to recommend - still tbd). That's not the case at WF192.

> One could also try 2^382-31, which would be much more similar to the
>gain at the lower security level.

"One" could try many things. But someone has to do the work to implement
and benchmark. I asked Mike to do some work here, because he had the tools
at his disposal, and he very kindly agreed to help - thanks again Mike. In
the interests of making progress, I'd encourage others to do more of the
same.

>Furthermore, if the faster one was more optimized, and the slower one
>not as much, that would be a reasonable conclusion. But we are
>comparing a C implementation written yesterday to a handwritten
>assembler one, with the C outperforming the assembly.

Yes, I'm aware of this. And so, like you (I infer), I'd expect the
currently faster one to improve more and the gap to widen further.

Cheers,

Kenny