You mean, besides recommending CTR but not telling his audience about nonce collisions and counter wraps?
I can find things to disagree with on many of these slides (avoiding NSA suite B crypto in favor of RSA-2048, using RSA-2048 directly, avoiding AE cipher modes in favor of hand-hacking your own encrypt-then-HMAC scheme). But Colin is the professional cryptographer here; all I have to go on is the crypto flaws we find in other people's real-world systems, and the simple steps I see people could have taken to avoid having them even without knowing about them.
You mean, besides recommending CTR but not telling his audience about nonce collisions and counter wraps?
Didn't I say "and make sure your nonces are unique"? I remember taking it out of a slide because it wouldn't fit but I was pretty sure that I still said it.
As for counter wraps, that really is a non-issue. Nobody here is ever going to send over 2^68 bytes of data in a single session.
Sigh. Colin, I brought it up for a reason: because we've found it before. I'm not going into more detail†. Take my word for it that this is something you need to be aware of if you're using CTR mode.
I just can't fathom the logic behind blowing off a potential crypto flaw that clearly can occur. What, to you, is the downside of letting people know that CTR can blow up in this manner?
† But, a hint, it has obviously never depended on us sending 295147905179 gigabytes to a target
Jiminy. This is like saying "if you're talking about a CTR implementation tht forgets to make nonces unique, that's a buggy CTR implementation". Well, no shit, Colin.
This case has the added benefit of you being wrong (the counterspace always starts at zero, but that doesn't mean decryption or encryption does).
You're drawing irrelevant distinctions here. If it was the case that you'd have to code your own entire implementation of the CTR mode of operation to have these bugs, I'd see your point.
Nobody here is ever going to send over 2^68 bytes of data
in a single session.
I think that's a flawed assumption. I don't think you shouldn assume that there will ever be a certain limit on the amount of data sent in a single session. People are paid (mountains worth) just to work toward breaking that assumption in the fastest time possible.
Anytime someone is paid money to break barriers I avoid betting against them.
> 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.
I can find things to disagree with on many of these slides (avoiding NSA suite B crypto in favor of RSA-2048, using RSA-2048 directly, avoiding AE cipher modes in favor of hand-hacking your own encrypt-then-HMAC scheme). But Colin is the professional cryptographer here; all I have to go on is the crypto flaws we find in other people's real-world systems, and the simple steps I see people could have taken to avoid having them even without knowing about them.