[Cryptography] NIST Workshop on Elliptic Curve Cryptography Standards

Tony Arcieri bascule at gmail.com
Fri May 15 21:20:03 EDT 2015


On Sat, May 16, 2015 at 7:52 AM, Ryan Carboni <ryacko at gmail.com> wrote:

> Look now I'm really confused. Before differential cryptanalysis, DES
> s-boxes were viewed with suspicion.
>
> 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."
>

That's not what I'm saying at all.

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.

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.

I suppose the most important takeaway I'm getting is that ECC is secure
> enough for obfuscation-grade cryptography.
> Otherwise one should should stick with 2048-bit RSA?


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.

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?

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)

Likewise, use of unpadded RSA is an exceedingly common error in
cryptographic programs.

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.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150516/e90f5585/attachment.html>


More information about the cryptography mailing list