Everything you need to know about cryptography in 1 hour, by Colin Percival | Hacker News Reader

Everything you need to know about cryptography in 1 hour, by Colin Percival

mefeedia.com

136 pointsibejoeb40 comments

From very early on in the talk:

"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! :)

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?

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.

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

a potential crypto flaw that clearly can occur

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.

We're getting near 20 questions territory here. I think I've made my point.

Well, would you mind humoring us? The unwashed masses...

Just make sure your counters can't wrap and you don't have this problem, noting that attackers will do things to try to force your counters to wrap.

If you're talking about starting the AES-CTR counter at 2^64-x, that's a buggy AES-CTR implementation: AES-CTR counters always start at zero.

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).

And: that's not all I'm talking about.

This is like saying "if you're talking about a CTR implementation tht forgets to make nonces unique, that's a buggy CTR implementation"

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.

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.

I suppose the point is that not everyone in your audience will be using 64-bit counters.

    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.

The bugs here have generally little to do with how much data you send.

If you send 2^68 bytes over a next-next-next-generation ethernet at 1 Tbps, you'll still run into the Y2038 bug before you finish.

Also, if you're sending more than 2^68 bytes of data, CBC is insecure too.

> Also, if you're sending more than 2^68 bytes of data, CBC is insecure too.

Can you explain why?

Birthday collisions.

You're so right.

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.

Hackerne.ws has a real panache for comedic timing.

The canonical URL is actually news.ycombinator.com

// Just thought you might like to know.

I know what the canonical name is, but that's not a name, it's a url.

This community is a 'thing' in and of itself and merits a name independent of a rather sterile subdomain.

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.

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 )

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.

aha. That makes a bit more sense. I was thinking 100K URL's was high even for a domainer.

Thanks for posting this. Here are the slides for those interested:

http://www.bsdcan.org/2010/schedule/attachments/135_crypto1h...

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.

Here's the original video page at blip.tv, with download link available: http://blip.tv/file/3627639

This quote is my favourite part of the conference:

"The purpose of cryptography is to force the US government to torture you."

That's my favourite line too -- I'm glad I'm not the only person who liked it. :-)

This is a good presentation. Unfortunately I'm not able to listen to it but the slides are informative.

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.

The video is not playing here. Was it removed?

Nevermind, noticed that it is going to Blip.tv, here it is on Blip.tv if the linked site doesn't work:

http://blip.tv/file/3627639/

Thanks for this, Colin. I've never heard him speak, and I respect the guy, but does anyone think comic book guy?

You "respect the guy", then throw out "comic book guy"? You think you're being funny. I'm guessing you're in the minority.

does anyone think comic book guy?

Hey, I know I could afford to lose a few pounds, but I'm not that overweight. ;-)

Reply on news.ycombinator.com