Don't Roll Your Own Crypto: Examples

Commentary::Crypto
Audience::Entry
UUID: bb828445-8bfc-4ccf-835b-5fdfa181ffc6

The usual reason given for asking software developers to not roll their own crypto is that anyone can build a cryptosystem that they cannot themselves break. That is perfectly true, but there don't seem to be many concrete examples that might convince the unwary. I'd like to provide a couple.

What most people see are references to Secretary of Defense Donald Rumsfeld's there are known knowns response to a question (much laughter from media pundits), and more scholarly approaches, such as calling it the Dunning–Kruger effect (a cognitive bias) after their widely-quoted Unskilled and Unaware paper.

Lots of people in the security trenches think of it simply as some_random_person who doesn't know that they have no freaking clue. That's a bit unfair, because we all do this, to some degree – that's the nature of a cognitive bias. For example, many people who can actually write would consider my blog posts a prime example. A more appropriate example would be the (several) people I have met who do networking, including quite competent jobs of network architecture, who have never read an RFC, and have only a vague idea of what the Internet Engineering Task Force (IETF) is. In many areas of IT, one can get by perfectly well without deep knowledge. There are fewer such areas in security, and none at all in cryptographic design and implementation.

The IETF are a great example for me to use, because I generally like to make more people aware of their existence, and, in this specific case because I recommend the IETF Crypto Forum Research Group Discussion Archive - Date Index as the first of those concrete examples. Read a few threads, and you will hopefully realize that this is something best left to specialists – those who have a made a career of it.

If that doesn't do it, have a look at Introduction to Modern Cryptography, by Katz and Lindell. You can look inside the second edition on Amazon. The first edition was a game-changer because it widely introduced provable security: the notion that rigorous mathematical proofs of the properties of a cryptosystem were the way forward. Provable security is one of the few means by which cryptography may get past the invent-break-fix stage. Here's a search onBirthday Attack, in the first edition at Google Books. Katz maintains a page on the book linking to reviews, courses where the book is used as a text, and errata, as well as a page on the page on the second edition.

On my shelves, I have only the first edition of Katz and Lindell, from 2007. It impressed me enormously, and now there is a second edition. So why aren't I talking about that edition? Because I am in no way qualified to roll my own crypto, and can't take years to learn the subject. My opinion would be irrelevant, even if I had one. Again, it's a very specialized thing, and unless you are both extremely clever, and willing to devote the better part of a career to it, you really shouldn't go there.

Also, please be aware that provable security is about algorithms. Implementations of those algorithms is a whole different thing, and we as yet have no complete solution to the implement-break-fix cycle. Crypto code is often complex, not least because it needs to defend against things like timing attacks. That famous line about "all bugs being shallow, given enough eyeballs," certainly does not apply here, where the essential requirement are those very few highly qualified eyeballs. Hopefully auditing well-commented code. Let me remind everyone that Heartbleed was an implementation bug, in one of the most widely used protocols (TLS, though also DTLS) crypto libraries (openssl), yet it remained undiscovered for two years.

So, for the third time, don't go there. Because there is already enough suffering in the world. Your time will likely be far better spent along the following lines.

• understanding what you are trying to secure, and from whom
• the strengths and weaknesses of various crypto suites and algorithms
• their applicability to the problem you are currently facing
• their suitability on your intended deployment platform

About this lack of recent posts

Sorry about that. Well, not really. It's been due to a combination of several things. Some professional stuff that I can't talk about, but mostly because Oregon in the summer. I am pretty outdoors-oriented in my off time, and needed to take advantage of the weather, which will be turning Pacific Northwest bad, which is famously bad, soon enough. 

I expect that now that the long Labor Day weekend is over, the pace will pick up a bit. Standing on the deck sipping coffee at 0530 this morning, with a half moon in the east, and Orion and the Pleiades almost at zenith was great, though I was listening for owls, and didn't hear any. And it wasn't so long ago that sunrise was at 0530, and none of this would have been seen. At the Winter Solstice, when there are less than 9 hours of any light in the sky, and it's likely to be pouring rain during those brief hours, I'll probably be posting a lot more often.