The past 5 years have not aged your aversion to elliptic curves very well. New modern designs by crypto specialists tend to be curve based. Curves also have a nice property in practice of tilting designs towards forward secrecy.
Naturally, we agree that devs shouldn't implement curves themselves --- but then, neither should they implement RSA-PSS. The right answer is to use Nacl, which is curve-based, but who cares? You're not interacting with that level of the design.
The past 5 years have not aged your aversion to elliptic curves very well. New modern designs by crypto specialists tend to be curve based.
The first of those statements does not follow from the second. I agree that there has been an increase in the usage of elliptic curves; but I've also seen a lot more attacks on elliptic curves recently than on RSA or DH(Z_p). Unless you have a particular need for small signatures (e.g., bitcoin) or maximal performance, I maintain that using elliptic curves is an unnecessary risk.
Curves also have a nice property in practice of tilting designs towards forward secrecy.
I'm not sure why you say this. DH has exactly the same PFS properties regardless of the group being used.
My claim about forward secrecy is easy to understand: ECC software doesn't encrypt directly, but RSA software easily can, and developers (for instance: Paul Kocher) give in to the temptation to use RSA encryption directly. RSA practically begs developers to create systems that aren't forward secure.
There is a lot of new attack research on ECC. But how much of that research implicates (a) common implementations of (b) the popular curves (NIST-Px, secpx, and Curve25519)? Inquiring minds, who have been implementing a lot of attack papers on artificially vulnerable curve software, want to know!
(Also, curve attacks that target DSA tend to be the fault of the DSA construction. I'm guessing this isn't the level at which you're thinking of curves being attack in the literature, though.)
Wasn't there an ECC side channel attack in OpenSSL just a week or two ago?
As for the more theoretical research -- none of it has been relevant to widely deployed systems yet, but this is the nature of research. Elliptic curves have a lot of structure which is still being explored, and as long as people continue to find attacks against new variants, I'm not going to bet that they'll never find attacks against the widely deployed systems.
I put being wary of ECC right now in the same category as being wary of SHA256 in 2006. It's not broken but there's a worrying amount of progress on related systems.
Fair enough, it was the secpxk1 curves that were broken in OpenSSL --- although that was a DSA vulnerability! It relied on a partial nonce leak! You're right, but I declare my wrongness to be defensible in this case.
If you're referring to the recent FLUSH+RELOAD attacks, that is hardly ECC-specific. They also owned GnuPG's RSA earlier with the same technique [1]. On the other hand, if your argument is that ECC implementations are generally less mature, I can't disagree with that. I believe that ECC (using Edwards or Montgomery forms; debatable when using general Weierstrass form) is easier to get right with respect to solid implementations than RSA is.
With respect to theoretical attacks, it is of course impossible to know what the future brings. But as long as we're sticking with conservative prime fields, I think it's probably either going to be fine or all of ECC is dead. It's also not like integer factorization or discrete logs have reached some kind of complexity lower bound; it's certainly not impossible that we'll get a L(1/4) method in the future as well. I look forward to see how it plays out.
It's also not like integer factorization or discrete logs have reached some kind of complexity lower bound; it's certainly not impossible that we'll get a L(1/4) method in the future as well.
Not impossible, no. But the fact that people have spent much longer looking for improved integer factorization attacks without making progress makes me more optimistic that integer factorization will continue to hold up to further scrutiny.
Since part of his argument is that it's especially easy to stumble into timing leaks with ECC implementations, it seems fair for him to call out OpenSSL's secp256k1 implementation.
