<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 16, 2015 at 7:52 AM, Ryan Carboni <span dir="ltr"><<a href="mailto:ryacko@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=ryacko@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">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 class="gmail_extra">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></blockquote><div><br></div><div>That's not what I'm saying at all.</div><div><br></div><div>BADA55 is a demonstration of why a "verifiably random" process, i.e. trying to pick curve parameters via the output of a, shall we say, "something potentially up my sleeve" number run through a hash function like SHA1, is a bad idea.</div><div><br></div><div>That's not how rigid curve generation works, however. Instead, we pick a set of constraints which generate curves that are not known to be susceptible to any attacks today. Instead of mystery constants, we encode our best knowledge about fast, secure ECC today into a constraint solver, and have that pick the curves for us.<br></div><div><br></div><div><blockquote 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" class="gmail_quote">I suppose the most important takeaway I'm getting is that ECC is secure enough for obfuscation-grade cryptography.<br>Otherwise one should should stick with 2048-bit RSA?</blockquote></div></div><div><br></div><div>Six of one, half dozen of another. Pollard's rho algorithms are still the best general case attack against both ECC and RSA. ECC and RSA are both special cases of the hidden subgroup problem.</div><div><br></div><div>You can worry about special case attacks against ECC which we can't foresee based on present knowledge, but why are those more likely than novel methods of factoring numbers, or improvements in index calculus attacks, both of which would affect only RSA but not ECC?</div><div><br></div><div>Hypothetical attacks aside, RSA has a lot of real problems in practice. Due to its susceptibility to index calculus attacks, large key sizes are used. We now have the uncomfortable tradeoff between amplification attacks (i.e. DDoS) in e.g. the DNSSEC case where the response includes an RSA public key or signature, or reducing the key size and thus the security margin (DNSSEC chose the latter... the root zone uses a 1024-bit ZSK)</div><div><br></div><div>Likewise, use of unpadded RSA is an exceedingly common error in cryptographic programs.</div><div><br></div><div>I would consider the use of RSA for anything other than legacy interoperability to be a code smell at this point. If you're creating a new pubkey protocol without legacy interop requirements today, you should probably be using ECC.</div><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>