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.
A Few Thoughts on Cryptographic Engineering 
what's wrong with Applied Cryptography (the book i presume)?
Would you really recommend NaCl? It looked promising at the time, but after over 10 months of no activity (including not even implementing Ed25519), it doesn't look all that enticing…
The short answer is that it was written in 1995. The long answer is: https://blog.cryptographyengineering.com/2011/11/in-defense-of-applied-cryptography.html
You could try libsodium which is a fork of NaCl: https://github.com/jedisct1/libsodium
I think the library itself is actively looked after by Peter, Tanja and Dan — so I _would_ feel confident that bugs and vulnerabilities will be quickly detected and fixed. New features are often the main driver of vulnerabilities.
Well, the NaCl website includes the following claim:
“WARNING: This signature software (both at the C level and at the C++ level) is a prototype.”
I am more than a bit leery of trusting a piece of software with this warning…
The alternative to using libraries and to using cut+paste is to use whole programs.
For “use Net::SMTP” do “exec('/usr/sbin/sendmail','-oi','-t')”.
Or call the ssh client or openssl binary for the current task. It keeps simple tasks simple which is a win for security.
I have seen an MSDN page (I no longer have the link, unfortunately) that was showing how to programmatically log on an user on the local machine… in about 250 lines of C++ code. Nowadays, it can also be done in about 2 lines of code.
I have seen MFC code for creating a window with a button on it… in about 80 lines of C++ code. Nowadays you don't even write code for it with a modern IDE.
We need something equivalent here. That GitHub link shows a ton of C code, which is completely meaningless to me. (And yes, I read Applied Cryptography :P) We (the non-crypto developers) need a high-level library that has a few clear calls. Even the MS Crypto API is far too complex. I need “encrypt / decrypt this text with this key”. I am willing to accept that I also need “store this key securely” (but I know a lot of developers who don't).
[None of this should be understood as saying “it's your fault”. Yes, it's our fault for not learning this stuff. But we'll keep not learning it until learning it is really easy… and unfortunately, we'll keep writing insecure applications because of that.]
Since tweetnacl wasn't exactly in a usable state, it had no header and no CSPRNG in use, I took it and added the things needed to make it usable, if anyone's interested in actually using this or wants to verify my use of OS CSPRNGs, please have a look.
https://github.com/ultramancool/tweetnacl-usable
Is TweetNaCl in the public domain, like the NaCl library?
According to copyright law (or what I know about that), if somthing is distributed in public domain, it should be explicitly written some where.