[Cryptography] Microsoft's new, free, crypto library dubbed FourQ
bascule at gmail.com
Sun Sep 20 00:30:11 EDT 2015
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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography