"Reality: Most applications only need a small set of well-understood standard idioms which are easy to get right."
Turns out that sentence was within a "n't" of being totally true! :)
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.
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.
// Just thought you might like to know.
This community is a 'thing' in and of itself and merits a name independent of a rather sterile subdomain.
I pointed it out because some people don't realise that is the URL.
But you piqued my curiosity. - http://hackerne.ws is regered to Yiannis Volos, (who seems to own about 100,000 domains --- http://whois.domaintools.com/hackerne.ws ) http://ycombinator.com is registered to Paul Graham (who seems to own about 46 domains http://whois.domaintools.com/ycombinator.com )
I forget the exact words, but the point read something like, "Don't think you've accomplished anything worthwhile if you place the hash and the file on the same web server." I agree with that, but am guilty of doing it all the time (as are others).
Does anyone have a link to the raw slides (PDF)? I downloaded them once, but lost them.
"The purpose of cryptography is to force the US government to torture you."
Colin, at about 26 minutes in your "DO" code is comparing the computed MAC with itself. I don't think that's what you want.
Nevermind, noticed that it is going to Blip.tv, here it is on Blip.tv if the linked site doesn't work:
Hey, I know I could afford to lose a few pounds, but I'm not that overweight. ;-)