<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 12:38 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, May 15, 2015 at 7:43 AM, Ryan Carboni <span dir="ltr"><<a href="mailto:ryacko@gmail.com" target="_blank">ryacko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>But my awareness of ECC issues is that the constants are suspicious according to this web page: <a href="http://safecurves.cr.yp.to/rigid.html" target="_blank">http://safecurves.cr.yp.to/rigid.html</a></div></div></blockquote><div><br></div></span><div>See also:</div><div><br></div><div><a href="http://safecurves.cr.yp.to/bada55.html" target="_blank">http://safecurves.cr.yp.to/bada55.html</a></div><div><br></div><div>This is a demonstration of how even though a "verifiably random" process (used by the NIST, Brainpool, and the GOST curves) is used, it's possible to tamper with curve parameters.</div><div><br></div><div>BADA55's tampering was not malicious (and in fact they are "safe curves" per <a href="http://safecurves.cr.yp.to" target="_blank">safecurves.cr.yp.to</a>), but the possibility to tamper with curve parameters exists in any curves generated this way.</div><div><br></div><div>This is why "nothing up my sleeve" curve constants generated through a rigid process are important (per your link).</div><span class="HOEnZb"><font color="#888888"><div> </div></font></span></div><span class="HOEnZb"><font color="#888888">-- <br><div>Tony Arcieri<br></div></font></span></div></div></blockquote><div> </div><div><br></div></div>Look now I'm really confused. Before differential cryptanalysis, DES s-boxes were viewed with suspicion.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But now people are saying, "we don't completely understand ECC, but we have devised means of creating EC and hope we get lucky and it ends up secure twenty years down the road."</div><div class="gmail_extra">Naturally RC4 as a cipher was created by accident. (and so was Penicillin as a drug)</div><div class="gmail_extra">But no one wants accidents in cryptography.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And I don't really trust any process that no one understands to protect anything important.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suppose the most important takeaway I'm getting is that ECC is secure enough for obfuscation-grade cryptography.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Otherwise one should should stick with 2048-bit RSA?</div><div class="gmail_extra"><br></div><div class="gmail_extra">But what would I know?</div></div>