> You mean, besides recommending CTR but not telling his audience about nonce collisions and counter wraps?
Oooh low blow! Point taken, but I think he did a pretty good job for 55 minutes. If someone decides to hand-roll AES-CTR, I'd say it's their job to go through all the literature (academic and otherwise), implement their own version and look at least a few open source implementations for differences, reconcile those difference (academic literature helps here), and then put their code up for review or audit. Perhaps even run several implementations through the same inputs and keys and compare outputs. Whether this actually gets done is of course a different issue.
So if I understand correctly, your objection to hand-rolling encrypt-then-HMAC is that it's rarely done correctly (not a theoretical objection)?
You don't have to "hand-roll" CTR mode to get this part wrong; you have to choose the nonce yourself, as the API user.
My objection to encrypt-then-HMAC is that it adds a moving part to your design that you have to get right. If your toolkit doesn't provide a well-implemented AE cipher mode, (a) you're doomed, but (b) yes, you should probably use HMAC rather than trying to hand-roll CBC-MAC for CCM mode.
Oooh low blow! Point taken, but I think he did a pretty good job for 55 minutes. If someone decides to hand-roll AES-CTR, I'd say it's their job to go through all the literature (academic and otherwise), implement their own version and look at least a few open source implementations for differences, reconcile those difference (academic literature helps here), and then put their code up for review or audit. Perhaps even run several implementations through the same inputs and keys and compare outputs. Whether this actually gets done is of course a different issue.
So if I understand correctly, your objection to hand-rolling encrypt-then-HMAC is that it's rarely done correctly (not a theoretical objection)?