Tweetnacl is a research project to improve the state of Erlang crypto.

API and codebase in flux while in v0.0.X, wear helmet while using.

Straight NaCl (well, libsodium) bindings would be useful but let's explore the design space for a moment.

Fail crypto is everywhere. Classes of failures, in order of increasing difficulty to exploit and avoid, are:

1. No encryption. (Too hard/no libraries.)
2. Broken by eavesdropping. (Nonce reuse/hardcoded keys/bruteforceable keys.)
3. Broken versus interaction. (No authentication/oracles/replay.)
4. Broken versus MITM. (Auth followed by plaintext session/no certificate pinning.)
5. Broken versus machine compromise. (Key theft/backdoors.)

There's also some stuff that's hard to place.

6. Broken code no one ever looks at.
7. Maintaining security during organic scope and feature growth.

This library tries to do a couple of things to tackle the above problems:

1. Try to avoid 1 2 and 3 by being as high level as possible. No confusing cipher options or moving parts. Move the primitives up a few levels.
2. Try to avoid 4 and 6 by reducing the cost of implementing key management. Specifically, try to provide a simple API for verifying short term keys.
3. Try to at least maintain confidentiality of old data during 5 by encouraging the generation of short term keys at an API level.

7 is an open problem.

I can try to avoid swapping-to-disk and properly erasing keys from RAM by writing a bunch of C, but that will bloat size. I want a tiny library. Key remanence is important for dealing with 5, but let's tackle 1-3 first.

This means keys being passed as Erlang binaries. Which means they'll be getting logged in crash messages, sent to log servers, and saved in crash dumps.

Comparing this binding to other projects, the major difference is binding to tweetnacl rather than libsodium/original NaCl. Other implementation differences:

• https://github.com/tonyg/erlang-nacl
  • Doesn't have all interesting primitives. I want symmetric + private.
• https://github.com/freza/salt
  • This one has very clean-looking code. Matches my original approach of by-the-book C, but finishes the job and publishes it first :)
  • As with tweetnacl vs libsodium, difference is in weight. I'll see how close I come to 1.4K lines of C depending on features and many macros I can justify using.

Don't think anyone's using PropEr tests, but given the domain that hardly matters :)

Oh yes. The original goal was also to look at applying Erlang API design to the problem of developer meets crypto code. This implementation may get creative with failure modes and naming schemes. (One man project, so no bike shedding.)