Just curious -- is there anything in particular that stood out? Other than the inherent troubles with implementing crypto, was there anything theoretically questionable with any of the talk's content?
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 get that there's a point to be made here to other people considering implementing their own crypto. But how is posting this anything other than kicking a man when he's down?
What better time to kick him? The point is not to make the guy feel bad, it's to drive home the point that even people of inordinate intelligence can and will get this stuff wrong. Hand-rolled crypto is like catnip to a certain class of programmer, since we all like to think we're brilliant enough to do it right if we just apply enough brainpower. This is a good object lesson we all need to learn from.
Sure. But the canonical name is Hacker News, HN for short. (Or Innocuous News when PG is feeling cheeky). And the canonical URL is news.ycombinator.com
I pointed it out because some people don't realise that is the URL.
whois.domaintools.com isn't following the WHOIS delegation for .ws, so it is the GoDaddy email address (dns@jomax.net) that appears to own 100,000 domains.
I think I saw the slides to this once. I don't have time to watch the video right now, but if it's the same presentation, he had a point about hashing a file and then uploading the file and the hash to the same web server for download.
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.
"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! :)