The reason you want to use EAX or CCM instead of CTR+HMAC is that EAX and CCM are standard constructions. CTR+HMAC isn't.
I don't know from where you get the idea that Encrypt-then-MAC is not a standard construction. Encrypt-then-MAC was a standard construction long before EAX and CCM were invented -- in fact, in the paper where EAX is introduced, it is actually defined as an Encrypt-then-MAC composition!
It's the places where primitives join together --- encryption with MAC, for instance --- where crypto protocols are broken.
If you look carefully at recent breaks, they have been in Encrypt-and-MAC and MAC-then-Encrypt -- both of which I specifically mention as inferior to Encrypt-then-MAC.
With all due respect to Colin, I think this take on how to minimize attack surface is, well, asinine. I think it's based on a bias against crypto library developers, based on the fact that Colin probably knows more about crypto than they do.
I apply the same approach of minimizing attack surface even when it's only my own code which is being attacked. The question isn't how prone some code is to vulnerabilities (although in the examples I gave, there certainly is a poor track record) -- the issue is engineering code to eliminate potential risks.
I don't find your argument particularly convincing. This "encrypt-then-MAC" thing is a total red herring. You're not advocating for the idiom. You're advocating for people to build their own nonstandard versions of it, because you don't like the library code that already exists for the standard versions.
Let's cut to the chase. I can point out HMAC vulnerabilities. Nate's Google Keyczar finding. SNMPv3. That's 15 seconds worth of research. [edit SSH screwed up HMAC as well.]
It should be at least as easy for you to give me two published implementation flaws in a CCM or EAX implementation. Go.
I can point out HMAC vulnerabilities. Nate's Google Keyczar finding.
Funny you mention that. The flaw Nate pointed out in Google keyczar can also affect CCM or EAX (or, for that matter, any authenticated encryption method).
It should be at least as easy for you to give me two published implementation flaws in a CCM or EAX implementation. Go.
Of course, neither of these two papers mention CCM or EAX -- but the flaws they mention apply to both CCM and EAX (because an attacker can cause you to input a block of his choice to your AES core) while not affecting CTR-then-HMAC.
First, the flaw in Keyczar didn't affect CCM (or CBC-MAC) or EAX (or OMAC).
Second, I cited SSH, SNMPv3, and Keyczar. You responded with localhost cache timing of AES and remote cache timing of naked AES. There's an obvious difference between the two sets: one consists of real attacks, the other of speculative attacks. If your point is valid, it shouldn't be hard for you to name one system in which CCM or EAX were "broken" --- and I'll give you any definition of broken you choose --- because of these papers.
They're both great papers. But I don't think they make the argument you think they do.
First, the flaw in Keyczar didn't affect CCM (or CBC-MAC) or EAX (or OMAC).
Of course not -- keyczar doesn't implement CCM or EAX. But the fact that CCM and EAX are obscure shouldn't count as a point in their favour.
There's an obvious difference between the two sets: one consists of real attacks, the other of speculative attacks.
The Bernstein and Oskiv-Shamir-Tromer attacks were not at all speculative. They showed the concrete theft of a key.
If your point is valid, it shouldn't be hard for you to name one system in which CCM or EAX were "broken" --- and I'll give you any definition of broken you choose --- because of these papers.
I don't know of any systems which use CCM or EAX in software on general-purpose hardware -- but if you name me a system which uses OpenSSL's AES code circa early 2005 in EAX mode, I'll name you a system which was vulnerable to a timing side channel.
Tally ho, Colin! Looking forward to what you find; I'm sure I'll learn something. If Bernstein's attack was really that relevant to real-world cryptosystems, I'm sure you'll come back with something fun.
I don't know from where you get the idea that Encrypt-then-MAC is not a standard construction. Encrypt-then-MAC was a standard construction long before EAX and CCM were invented -- in fact, in the paper where EAX is introduced, it is actually defined as an Encrypt-then-MAC composition!
It's the places where primitives join together --- encryption with MAC, for instance --- where crypto protocols are broken.
If you look carefully at recent breaks, they have been in Encrypt-and-MAC and MAC-then-Encrypt -- both of which I specifically mention as inferior to Encrypt-then-MAC.
With all due respect to Colin, I think this take on how to minimize attack surface is, well, asinine. I think it's based on a bias against crypto library developers, based on the fact that Colin probably knows more about crypto than they do.
I apply the same approach of minimizing attack surface even when it's only my own code which is being attacked. The question isn't how prone some code is to vulnerabilities (although in the examples I gave, there certainly is a poor track record) -- the issue is engineering code to eliminate potential risks.