[Cryptography] On the use of TweetNaCl as a standard cryptography library

[Patrick Chkoreff]

I've been working with TweetNaCl lately, in particular embedding its
functions into my functional programming language Fexl.  I like its
authenticated encryption routines, which I have embedded as:

  (crypto_box_seal plain_text nonce key)   # Encrypt the plain text.
  (crypto_box_open crypt_text nonce key)   # Decrypt the crypt text.

(Note that Daniel Bernstein has designed these functions to guarantee
repudiability, while still protecting the sender and receiver against
forgeries.)

The "key" argument to those functions is derived differently by the
sender and receiver, using this function:

  (crypto_box_prepare public_key secret_key)

  # Combine the 32-byte public and secret keys into a 32-byte composite
  # key which is used with crypto_box_seal and crypto_box_open.
  #
  # When sending, use the recipient's public key and the sender's secret
  # key.  When receiving, use the sender's public key and the
  # recipient's secret key.

A secret key is an arbitrary string of 32 bytes, which I read directly
from /dev/urandom using:

  random_secret_key  # Returns a string of 32 random bytes.

A public key is derived as a deterministic function of a secret key with
this function:

  (crypto_box_public secret_key)

  # Map the 32-byte secret_key into the corresponding 32-byte public
  # box key.

A nonce is an arbitrary string of 24 bytes, which I read directly from
/dev/urandom using:

  random_nonce  # Returns a string of 24 random bytes.


(In addition, for plain signatures, there is a similar set of functions
crypto_sign_public, crypto_sign_seal, and crypto_sign_open.  However
these are not needed for ordinary authenticated communication.)


I regard this cryptographic protocol as a sort of "ultimate" toolbox, at
least until the fabled quantum computers come along.  The TweetNaCl
library is very efficient, and I trust that Bernstein has made it
extremely secure -- as much as I can trust *anyone* working in this space.

However, I must ask, is my appraisal justified?  Are there problems with
the protocol, or its specific implementation in TweetNaCl?  Does the
library fail to address any issues which arise in practical
applications?  In an ideal world, if "everyone" standardized on this
library, what problems might arise, including vulnerabilities,
inefficiencies, or missing features?  In other words, why isn't this
"the last word" on cryptographic protocols, given our current
understanding, and discounting quantum computers?  It's an open-ended
question, and I'm not married to any particular answer.


-- Patrick