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.
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
Well, that's the thing. I can't see how CTR counter wraps can occur. 64-bit counters which start at zero simply don't wrap.
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).
And: that's not all I'm talking about.
No, it isn't. The CTR counter is part of the implementation; the nonce is part of how CTR is used by the application.
(the counterspace always starts at zero, but that doesn't mean decryption or encryption does
If you're not encrypting starting from a counter of zero, you're not using a stream cipher. (Most likely, you're using a block storage cipher.)
And: that's not all I'm talking about.
Ok. I was just guessing, because you're claiming that an impossible bug exists and refusing to give any details.
Nobody here is ever going to send over 2^68 bytes of data
in a single session.
Anytime someone is paid money to break barriers I avoid betting against them.
Also, if you're sending more than 2^68 bytes of data, CBC is insecure too.
Can you explain why?
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)?
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.