[Cryptography] Microsoft's new, free, crypto library dubbed FourQ

[Rob Schneier]

I was asked for the context of the discussion. Here it is.



On Sat, Sep 19, 2015 at 9:30 PM, Tony Arcieri <bascule at gmail.com> wrote:

> On Sat, Sep 19, 2015 at 11:38 AM, Rob S. <rob.schneier1 at gmail.com> wrote:
>
>> Tony Arcieri's post is full of misconceptions and mistakes.
>>
>
> Oh really!
>
>
>> Most of the recent Kummer implementations (see
>> http://eprint.iacr.org/2012/670.pdf and
>> http://eprint.iacr.org/2014/134.pdf) are fully optimized in assembly.
>
>
> Cool claim, it's both vague and not true in places where it really matters.
>
>
>> Still, I see that FourQ is significantly faster when looking at different
>
> 64-bit processors (check out Table 5 in the FourQ paper,
>> http://eprint.iacr.org/2015/565.pdf). If one looks across different CPUs
>> (not only one CPU in particular)
>
>
> Funny thing, I know you really don't want to for some reason, but if we do
> look at one CPU architecture, there's a rather important one that Kummer
> hasn't been optimized for. I'll just quote djb...
>
> On Tue, Sep 15, 2015 at 8:49 AM, D. J. Bernstein <djb at cr.yp.to> wrote:
>
>> The critical statement is "59,000" Haswell cycles for FourQ, compared to
>> 60556 Haswell cycles (reported by eBATS) for Kummer.
>>
>> What's amusing about this is that Haswell is the only platform where we
>> didn't bother writing an asm implementation for Kummer---this is a very
>> simple C implementation with intrinsics. Anyone want to bet on what the
>> results of an asm implementation will be?
>
>
> I guess your point is why should we care about Haswell? Well, I certainly
> care about Haswell and its progeny even if you don't...
>
> djb has several other criticisms of the performance metrics in the FourQ
> paper. Microsoft also has a history of over-embellishing the performance of
> e.g. the NUMS curves. Perhaps some independent verification is needed
> before the figures in their paper are taken at face value?
>
> This is why benchmarking systems like SUPERCOP are nice.
>
> --
> Tony Arcieri
>



On Fri, Oct 2, 2015 at 12:01 PM, Rob Schneier <rob.schneier1 at gmail.com>
wrote:

--- Apologies for the late reply. Coming back from vacation.

I can see that you like dodging and avoid acknowledging your mistakes. But
let me keep readers well informed:



You originally said: "djb and friends' Kummer curve is ..."

I clarified that you were wrong and that "efficient scalar multiplications
on the Kummer surface and the fast Kummer surface defined over GF(2^127-1)
used by several recent implementations are due to Gaudry and Gaudry-Schost,
respectively, not to "djb and friends"."

What you responded back: nothing.



You originally said: "(Kummer) hasn't been assembly optimized yet."

I clarified that your statement was false and that "most of the recent
Kummer implementations (see http://eprint.iacr.org/2012/670.pdf and
http://eprint.iacr.org/2014/134.pdf) are fully optimized in assembly."

What you responded back: "Cool claim, it's both vague and not true in
places where it really matters."

Sorry for speaking with facts: the papers that I cited report results "on
an Intel Core i7-3520M (Ivy Bridge) processor" in the case of [1], and on
Sandy Bridge, Ivy Bridge and Haswell in the case of [2] ([2] also reports
results on ARM Cortex-A8). *ALL* the implementations excepting the one for
Haswell *ARE* assembly optimized (checking this takes no effort, just check
out SUPERCOP or the papers). Haswell is important but it is not the only
processor family that matters in the world.



You said: "I guess your point is why should we care about Haswell? Well, I
certainly care about Haswell and its progeny even if you don't...".

Huh? Please, do not fabricate arguments just because you don't know about
this topic.



You said: well, quotes and opinions from djb.

If I want to read others' opinions I just do it. Sorry but I expect people
to use their own opinions and ideas when posting, instead of just
copy-and-pasting opinions from others.


Sincerely,

Rob Schneier



[1] J. W. Bos, C. Costello, H. Hisil and K. Lauter, "Fast Cryptography in
Genus 2".

http://eprint.iacr.org/2012/670.pdf

[2] D. J. Bernstein, C. Chuengsatiansup, T. Lange and P. Schwabe, "Kummer
strikes back: new DH speed records".
http://eprint.iacr.org/2014/134.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151003/33b3ffd0/attachment.html>