About a year ago I got into a discussion on Twitter with a couple of other cryptographers. The subject: why do so many software developers use lazy cryptography?
The instigation for this discussion was actually a piece of malware -- a popular, widespread botnet that forgot to use digital signatures to sign its control messages. Though I know it's wrong to complain about broken malware, at the same time: these idiots had money on the line! If they couldn't bother to properly secure their software, how can we possibly expect, say, Evernote to get it right?
And indeed, the more you look at software, the more you realize this problem cuts across all types of software development. People suddenly find themselves in a position where they could really use strong cryptography (be it ciphers, signatures, collision-resistant hash functions) but instead of buckling down and doing it right, the developers inevitably opt for something terrible.
Terrible can mean a lot of things in this context. Mostly it means using no crypto at all. Sometimes it's grabbing an RC4 implementation off of Wikipedia. Or copying something from Applied Cryptography. Or in a few borderline cases, grabbing the MS Crypto API and thus getting stuck with a basket of legacy algorithms thanks to ancient Windows XP compatibility issues.
Anyway, the problem -- it seemed to us at the time -- wasn't just a lack of knowledge, or even an absence of good crypto libraries. Rather, the problem was that you had to use libraries. If your developer has hit the point where s/he's willing to copy and paste RC4 from Wikipedia, you're already in a kind of Fifth Dimension of laziness. Nobody's going to pull in NaCl or OpenSSL just to encrypt one little blob of text.
The output of all this thinking was a grand vision. If we couldn't bring the developers to the crypto, we would bring the crypto to the developers. Specifically, we'd develop an easy to use crypto library small enough that you could copy and paste it right into your code. Since we were already using Twitter, we had a metric for complexity right there: the entire library would have to fit in a small number of Tweets. Jean-Philippe Aumasson (developer of the SHA3 finalist BLAKE) even laid the cornerstone by developing TweetCipher, an entirely new authenticated cipher that fits in about six Tweets.
It was an exciting time. We dreamed big! We made big plans! Then -- this being Twitter -- we got distracted by something shiny and forgot all about it.
Fortunately others have risen to carry on our great work. Tonight marks the publication of TweetNaCl, a re-implementation of the NaCl crypto library that fits in exactly 100 Tweets. TweetNaCl is brought to you by the same people who wrote NaCl, which means that it's probably quite good. More to the point, it's actually compatible with NaCl, which means it uses standard and well-vetted algorithms. (Here's the code in indented, non-Tweet form.)
Would I recommend you use TweetNaCl? Well, no. I'd recommend you use the real NaCl. But if you do find yourself with a crypto problem, and it looks like you're just about to copy code from Wikipedia.... Then maybe TweetNaCl could be just the thing.