Encrypt-then-HMAC has been a widely used standard for the past decade, and has been extensively studied.
A simpler recommendation would have been to use CCM or EAX mode.
AES-CTR and HMAC-SHA256 are far more simple than AES-CCM or AES-EAX. AES-CTR plus HMAC-SHA256 is also far more secure against side channel attacks, and has the advantage of allowing you to separate authentication from encryption -- useful if, say, you want to include some unencrypted data in an authenticated packet as well.
Key size and hash function selection (as long as you're not using MD5) are the least important design considerations you have.
I didn't mean to imply that all of the issues I mentioned were very important. My selection was more or less done on the basis of "what questions have people asked me recently?"
If you follow all of Colin's recommendations here from scratch in a reasonably complicated, and you have never found a crypto vulnerability or fixed two reported crypto vulnerabilities, I will bet $500 that you end up with a broken system.
That's probably a safe bet. I think it would be an even safer bet if you made it with someone who didn't follow my recommendations.
Your first point, about how well-studied HMAC is vs. CCM, is one of those points that makes a lot of sense in an academic context and much less sense in practice. In an academic context you assume both implementations are sound. In a practical context, you have to consider how likely it is that the implementor is going to make unsound choices.
The same goes double for your second point. Yes, if you have to implement the MAC yourself, you clearly want to use HMAC rather than trying to get CBC-MAC right. But if you're in a place where you have to implement your own MAC, you are doomed for a bunch of other reasons. CCM is preferable to HMAC because it's likely you're going to simply be able to change CTR to CCM and have it.
I didn't say anything about implementing the MAC yourself. Someone has to implement it, though -- and no matter who writes the code, HMAC-SHA256 is far more likely to be right and not leaking data via side channels than CBC-MAC is.
Bespoke CBC-MAC is an almost-certain disaster. HMAC-SHA256 has some obvious implementation failure modes. It's less easy to see how someone screws up typing "CCM" into their library.
The point is that there are already shrink-wrapped AE constructions (like CCM or EAX) that you can pick up off the shelf and use; HMAC designs are more likely to be bespoke.
It's less easy to see how someone screws up typing "CCM" into their library.
If you trust the library, sure. But I've found that the same rules apply to crypto libraries as to everything else: Obscure and complicated features are far more likely to be buggy.
No crypto library is ever going to ship with a broken HMAC-SHA256 -- but I can't say the same thing about AES-CCM.
Seriously, Colin? You're talking about people that don't know to use AES-256 instead of Blowfish, but do know enough to homebrew instead of using a library?
CCM and EAX aren't obscure. AE crypto has been in 3 of the last 4 designs I've had to review. The fourth prompted a recent blog post of mine.
Encrypt-then-HMAC has been a widely used standard for the past decade, and has been extensively studied.
A simpler recommendation would have been to use CCM or EAX mode.
AES-CTR and HMAC-SHA256 are far more simple than AES-CCM or AES-EAX. AES-CTR plus HMAC-SHA256 is also far more secure against side channel attacks, and has the advantage of allowing you to separate authentication from encryption -- useful if, say, you want to include some unencrypted data in an authenticated packet as well.
Key size and hash function selection (as long as you're not using MD5) are the least important design considerations you have.
I didn't mean to imply that all of the issues I mentioned were very important. My selection was more or less done on the basis of "what questions have people asked me recently?"
If you follow all of Colin's recommendations here from scratch in a reasonably complicated, and you have never found a crypto vulnerability or fixed two reported crypto vulnerabilities, I will bet $500 that you end up with a broken system.
That's probably a safe bet. I think it would be an even safer bet if you made it with someone who didn't follow my recommendations.