Security considerations

The current implementation takes the well-tested and hard-to-misuse secretbox authenticated encryption primitive from NaCl, and combines it with the STREAM encryption protocol from [HR+15].

The security of this library therefore depends on three factors:

1. The security of NaCl, and the secretbox primitive in particular. NaCl is very well respected and generally seen as providing high-quality crypto. This factor is not a concern.

2. The security of the STREAM construction. The paper where it is defined comes with a security proof that reduces it to the security of the underlying authenticated encryption primitive. Also, Phil Rogaway is on the authors list. I don’t think this factor is a concern either.

3. The correctness of this implementation. This factor is the problem, because the implementation is written by me.

While I have an interest in cryptography, I am not exactly experienced. I have avoided all of the mistakes I know not to make; I can do nothing about the ones I don’t know about. As of yet, no other person has reviewed this implementation.

In many ways, you could probably do worse than using this library. But my recommendation is that you don’t use this library to protect sensitive data. I simply can’t guarantee that it’s safe.

HR+15

Hoang V.T., Reyhanitabar R., Rogaway P., Vizár D: Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance. In: Gennaro R., Robshaw M. (eds): Advances in Cryptology – CRYPTO 2015. CRYPTO 2015. Lecture Notes in Computer Science, vol 9215. Springer (2015) [eprint]