Conservative, misuse-resistant crypto in Erlang.
C Erlang
Latest commit a159c65 Apr 22, 2014 @amtal Usage examples.
Why am I adding examples? For copy-pasteable code? To show off
useful simplifying tricks people should know? Or to cover pain
points/traps that are easy to run into?
Permalink
Failed to load latest commit information.
c_src
include Segfaults?! In my code? Apr 11, 2014
src
test Fix misuse of scratchspace for sign_open. Apr 11, 2014
.gitignore Am starting to be happy with tradeoffs selected. Feb 8, 2014
Makefile Refactor for simplification. Apr 5, 2014
README.md
rebar.config Am starting to be happy with tradeoffs selected. Feb 8, 2014

README.md

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.

Design Considerations

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

Failures Modes Addressed

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.

  1. Broken code no one ever looks at.
  2. 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.

Failure Modes Not Addressed

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.

Alternative NaCl/libsodium Bindings

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.)