You are entitled to your opinions, no matter how wrong they are. ;-)
Elliptic curves were proposed, and have since been studied in the context of cryptography, in 1985. They're 30 years old! For comparison, finite field discrete-log Diffie-Hellman is 38 years old, and RSA is 37. The latter have been severely beaten down in the ensuing decades that followed, whereas elliptic curves have stayed (modulo special cases, but those also exist for DH/RSA) resistant to every non-generic attack so far. I would say ECC has a better track record, and could be considered the conservative choice.
It could be argued that the underlying problem, integer factorization and FF discrete log, has been studied for much longer than the ECDLP. Maybe. Some basic algorithms go centuries back, but I would argue that the field has only seen real progress starting in the mid-1970s, with CFRAC and Pollard's algorithms. It can be counter-argued that elliptic curves as a subject have only existed for around 100 years, so they are still underdeveloped. Again, maybe.
There is indeed a new wave of interest in elliptic curves, and it is still fueling many publications every year. But these are mostly performance engineering at this point: Edwards curves are not fundamentally different from what Miller proposed in 1985, as far as the ECDLP is concerned. I would not recommend the wonkier stuff like GLS/GLV curves, though, nor curves over extension fields or of higher genus: that would be too neophiliac, even for me.
(I realize that I'm not gonna change your (or probably anyone's) mind, but you make it sound like elliptic curves are much more of a novelty than they really are. I don't disagree too much about the AEAD vs CTR+HMAC issue.)
Both CTR+HMAC and combined AEAD modes, correctly implemented and correctly used, will keep you safe against existing published attacks. Thomas takes the view that "correctly implemented and correctly used" is a problem, and I'll accept that he's right to recommend AEAD modes in that case (as long as you have a good cryptographic library[1] available to you).
I take the view that if you can't take CTR and HMAC and put them together correctly, there's no way the rest of your code is ever going to be secure, so you've already lost; so I focus on the "against existing published attacks" side of things, look at the places where novel cryptographic attacks tend to be found, and opt for combining two very simple and well-understood constructions.
The same story plays out for RSA vs. ECC: Thomas is worried about the fact that people have made dumb mistakes when using RSA, while I figure that if you're going to make those dumb mistakes (especially after my talk) you're going to write code which is otherwise insecure anyway, so I focus on the places where I think it is more likely that attacks will be found in the future[2].
If you're a high school student with two years of Python experience and you want to add some cryptography to your cat photo sharing startup, listen to Thomas. If you're a senior developer with 20 years of experience writing C code for internet-facing daemons, and the code you write is going to be used by democracy activists in China, listen to me.
[1] I'm not convinced that such a thing exists right now. [2] Or, alternatively, where attacks may have already been found, but not published.
Also, if you asked me who was more likely to get crypto right, the Django web guy or the C daemon guy, I'd bet on the Django guy every time. Betting against crypto implemented in C is like betting when you've made a full house on the flop: all in.
I have to agree with Colin's [1] point.
The standard libraries for the languages I see in assessments most often just don't include AEAD constructions. And when public libraries exist, they haven't been properly assessed.
* OpenSSL supports AEAD through CCM and GCM (and OpenSSL's GCM uses PCLMUL and shouldn't have the obvious cache leak)
* Botan supports AEAD through OCB, GCM, CCM, EAX, and SIV(!).
* Java JCE with the Bouncycastle provider (extremely popular) does AEAD with GCM, CCM, and OCB
* .NET stack languages get AEAD through CCM or GCM.
* Crypto++ supports AEAD with GCM, CCM, and EAX.
* Golang supports AEAD through GCM in the standard library (I did implement a crappy OCB myself, but the go.crypto package probably has a better one).
What bases aren't covered here? Bear in mind that most languages get their crypto through bindings to OpenSSL.
But .NET probably represents the largest block of applications I see. Seconded by (shudder) CF. I don't really have any hope for CF but crypto is hardly it's biggest problem.
As far as .NET goes, my first point was that the standard library does not support it; true in this case. I'm aware of CLR and Bouncy Castle as external libraries but neither of them inspires me with confidence.
Supposedly, CLR was released by Microsoft but why didn't they include it in the standard library or release any associated security assessment reports? Were there any?
I've heard the name Bouncy Castle thrown around quite a bit but that's about it. When I dig through their websites, it leaves me with a feeling not unlike trying to find information about Truecrypt. Granted, I haven't followed their project(s) very closely. But because of that feeling, I honestly trust OpenSSL more because people are scared about it.
So, maybe I'm just missing something but this is where I've arrived. Please correct me if I'm way off base.
Somewhat disappointing, since this slide is the only one in the presentation containing anything cryptographically "meaty".
(I know that ideal ciphers are defined correctly elsewhere, and agree that their definition makes sense.)
True, I oversimplified a bit. I was referring to situations where you don't know k' and x', e.g., x' = x and k' = k ^ \epsilon for some value \epsilon.