A crypto library aimed at auditability

There are a number of free software cryptographic libraries out there, but they tend to be focused on things like performance and being full-featured, rather than other attributes like readability or auditability. But the TweetNaCl project [PDF] is targeting its efforts at a simple, easy-to-read library that still provides strong cryptography and protects adopters from timing attacks. In fact, as the name might indicate, TweetNaCl is so small that it was sent out as 100 tweets on Twitter.

TweetNaCl is an outgrowth of the NaCl project (NaCl stands for "Networking and Cryptography library" and is pronounced "salt"), which is an effort to provide "all of the core operations needed to build higher-level cryptographic tools". It does so by providing a selected set of cryptographic algorithms with few or no options (e.g. key size), rather than take the toolkit approach of OpenSSL and other libraries that provide many different algorithms and options. The NaCl core team consists of Daniel J. Bernstein (djb of qmail and other networking-and-security tool fame), Tanja Lange, and Peter Schwabe. NaCl and the cryptography it implements is described at some length in a paper [PDF] by Bernstein.

TweetNaCl takes the NaCl API, some 25 functions that can be called by applications, but implements them in readable C code. The optimizations, assembly code, and other performance shortcuts taken by NaCl are gone.

Given that 100 tweets could contain at most 14,000 characters, it won't come as a surprise that tweetnacl.c (the source can also be found in the paper or slightly rearranged in this GitHub repository) comes in at 13,438 bytes in length. That is the size of the compressed version of the code (so it could fit in 100 tweets); the human-readable version is 809 lines and 16,621 bytes—still quite manageable.

According to the TweetNaCl paper (which was written by the core NaCl team plus Wesley Janssen), NaCl is "rapidly becoming the crypto library of choice for a new generation of applications". That is the reason it was chosen as the API for the simple, auditable cryptographic library that became TweetNaCl. The idea is that TweetNaCl is "short enough and simple enough for humans to audit against a mathematical description of the functionality in NaCl" such as that in Bernstein's NaCl paper. That doesn't complete the auditing process, though, as the TweetNaCl paper warns: "Of course, compilers also need to be audited (or to produce proofs of correct translations), as do other critical system components."

The readability of the code affects its performance somewhat, but the claim is that TweetNaCl is fast enough for typical applications that just need to do some low-volume cryptographic operations. So an application project could potentially audit the correctness of the code it uses for cryptography, which is something that is difficult or impossible to do with other libraries. In addition, the NaCl high-level API makes it difficult to choose a poor combination of algorithms that lead to bad security:

TweetNaCl also follows NaCl's lead in avoiding timing-based attacks. It does so by not having any branches or array indices that depend on secret data. It is also thread-safe and does no dynamic memory allocation. It is completely compatible with NaCl and has been verified using the NaCl test suite.

The algorithms provided by TweetNaCl (and, of course, NaCl) are generally ones that Bernstein has published including the Salsa20 stream cipher family, the Poly1305 message authentication code (MAC), and the Curve25519 Diffie-Hellman key exchange. It also uses SHA-512 for cryptographic hashing.

The code for both TweetNaCl and NaCl have been placed into the public domain, so they are freely available. It will be interesting to see if projects start to use TweetNaCl, or at least provide it as an option. NaCl is used in a number of recent applications including BitTorrent Live and DNSCrypt; it is destined for the next generation of the Tor protocol as well. Replacing NaCl with a compatible, auditable library seems like it might be a good option, especially for Tor.

The fact that TweetNaCl is small and auditable doesn't mean that the audit work has been done, however. It would be nice to see some project or projects take on the auditing of TweetNaCl and publicly report the results. A reasonably careful project would not rely on another project's audit alone, of course, but if enough projects do some auditing, some level of trust in the code will be built. That would lead to quite a different situation than we have with today's cryptographic applications.