<div dir="ltr"><div>I was asked for the context of the discussion. Here it is.</div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 19, 2015 at 9:30 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 19, 2015 at 11:38 AM, Rob S. <span dir="ltr"><<a href="mailto:rob.schneier1@gmail.com" target="_blank">rob.schneier1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Tony Arcieri's post is full of misconceptions and mistakes.<br></blockquote><div><br></div><div>Oh really!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Most of the recent Kummer implementations (see<br><a href="http://eprint.iacr.org/2012/670.pdf" target="_blank" rel="noreferrer">http://eprint.iacr.org/2012/670.pdf</a> and<br><a href="http://eprint.iacr.org/2014/134.pdf" target="_blank" rel="noreferrer">http://eprint.iacr.org/2014/134.pdf</a>) are fully optimized in assembly.</blockquote><div><br></div><div>Cool claim, it's both vague and not true in places where it really matters.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Still, I see that FourQ is significantly faster when looking at different</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">64-bit processors (check out Table 5 in the FourQ paper,<br><a href="http://eprint.iacr.org/2015/565.pdf" target="_blank" rel="noreferrer">http://eprint.iacr.org/2015/565.pdf</a>). If one looks across different CPUs<br> (not only one CPU in particular)</blockquote><div><br></div><div>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...</div><div><br></div><div>On Tue, Sep 15, 2015 at 8:49 AM, D. J. Bernstein <span dir="ltr"><<a href="mailto:djb@cr.yp.to" target="_blank">djb@cr.yp.to</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">The critical statement is "59,000" Haswell cycles for FourQ, compared to<br>60556 Haswell cycles (reported by eBATS) for Kummer.<br><br>What's amusing about this is that Haswell is the only platform where we<br>didn't bother writing an asm implementation for Kummer---this is a very<br>simple C implementation with intrinsics. Anyone want to bet on what the<br>results of an asm implementation will be?</blockquote></div></div><div><br></div><div>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...</div><div><br></div><div>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?</div><div><br></div><div>This is why benchmarking systems like SUPERCOP are nice.</div><span><font color="#888888"><div><br></div>-- <br><div>Tony Arcieri<br></div></font></span></div></div></blockquote></div><br></div></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 2, 2015 at 12:01 PM, Rob Schneier <span dir="ltr"><<a href="mailto:rob.schneier1@gmail.com" target="_blank">rob.schneier1@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">--- Apologies for the late reply. Coming back from vacation.</font><font color="#000000" face="Calibri" size="3"><br></font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">I can see that you like dodging and avoid acknowledging your mistakes. But let me keep readers well informed:</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3"> </font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">You originally said: "djb and friends' Kummer curve is ..." </font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">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"."</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">What you responded back: nothing.</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3"> </font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">You originally said: "(Kummer) hasn't been assembly optimized yet."</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">I clarified that your statement was false and that "most of the recent Kummer implementations (see <a href="http://eprint.iacr.org/2012/670.pdf" target="_blank">http://eprint.iacr.org/2012/670.pdf</a> and <a href="http://eprint.iacr.org/2014/134.pdf" target="_blank">http://eprint.iacr.org/2014/134.pdf</a>) are fully optimized in assembly."</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">What you responded back: "Cool claim, it's both vague and not true in places where it really matters."</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">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.</font><span><font color="#000000" face="Calibri" size="3">  </font></span></p><p style="margin:0in 0in 8pt"><span><font color="#000000" face="Calibri" size="3">   </font></span></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">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...".</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">Huh? Please, do not fabricate arguments just because you don't know about this topic.</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3"> </font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">You said: well, quotes and opinions from djb.</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">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.</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3"><br></font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">Sincerely,</font> </p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">Rob Schneier</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3"> </font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">[1] J. W. Bos, C. Costello, H. Hisil and K. Lauter, "Fast Cryptography in Genus 2".</font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3"><a href="http://eprint.iacr.org/2012/670.pdf" target="_blank">http://eprint.iacr.org/2012/670.pdf</a></font></p><p style="margin:0in 0in 8pt"><font color="#000000" face="Calibri" size="3">[2] D. J. Bernstein, C. Chuengsatiansup, T. Lange and P. Schwabe, "Kummer strikes back: new DH speed records".</font></p><span style="line-height:107%;font-family:"Calibri",sans-serif;font-size:11pt"><font color="#000000"><a href="http://eprint.iacr.org/2014/134.pdf" target="_blank">http://eprint.iacr.org/2014/134.pdf</a></font></span></div>
<br></div></div>