Consider using NaCl

[moul]

Topics to explore:

• compare with enclave
• compare with software non-NaCl implementation
• pros/cons depending on the usages, when to use?
• is it better to support multiple algorithm and algorithm versionning?

[glouvigny]

compare with enclave

NaCl (or Libsodium or other compatible forks) is potentially less secure than the enclave as it only uses a software implementation.

NaCl is designed to exchange data on the internet: no obscure structures, everything is stored as a string ready to be shared/stored. Enclave is more a low level (everything is performed on a secured memory and processor area but more logic has to be defined)

We assume here that the enclave doesn't have a hardware flaw/backdoor.

compare with software non-NaCl implementation

NaCl uses simple primitives (ie. encrypt/decrypt)

The main analogy used to differenciate NaCl and an implementation using OpenSSL is the Elevator vs Space Shuttle comparison:

• A Space Shuttle (OpenSSL custom implementation) is hard to operate (here's a space shuttle dashboard - you have to choose your algorithms, check errors, ensure the signature is valid etc.)
• An elevator is easy to use, so is NaCl (going to 5th floor using the elevator)

For instance the encrypt function (crypto_box) takes four parameters:

• a message to encrypt (m)
• a nonce that has to be known be the receiver (n)
• receiver public key (pk)
• sender secret key (sk)

The equivalent custom implementation would go through the following steps (example given on NaCl's website):

• Generate a random AES key.
• Use the AES key to encrypt the message.
• Hash the encrypted message using SHA-256.
• Read the sender's RSA secret key from "wire format."
• Use the sender's RSA secret key to sign the hash.
• Read the recipient's RSA public key from wire format.
• Use the recipient's public key to encrypt the AES key, hash, and signature.
• Convert the encrypted key, hash, and signature to wire format.
• Concatenate with the encrypted message.

Another example, the decrypt primitive (crypto_box_open) will perform all the nessesary checks before decrypting the message.

crypto_box_open takes the following parameters (it is basically the opposite of crypto_box) :

• encrypted text (c)
• a nonce (n)
• sender public key (pk)
• receiver secret key (sk)

and it will ensure that the message is signed by the sender (a check will be performed against the public key and the secret key provided).

pros/cons depending on the usages, when to use?

Pros

• Dead simple to use
• Secure by default
• Designed for data transmission
• Available in plenty of languages (should not be a problem if we plan to have encryption handled client side for the web version or if we have a bot platform in other languages than Go)
• Optimized for every processor architecture

Cons

• Less customizable
• Black box, you don't choose which algorithms are used, it is opinionated and may not suit our needs (we may face issues with deniability and/or forward secrecy)
• String serialization, no binary mode by default
• Non-compatible with a non NaCl solution

is it better to support multiple algorithm and algorithm versionning?

We should have a way to deprecate an encryption method, but we also have to care about devices running older versions of the app and that won't be able to open the messages (how to gracefully handle those)

tl;dr

NaCl seems nice but may not suit our need depending how we want to manage forward secrecy and privacy

[moul]

Thank you for your feedback

Maybe we can keep nacl in mind for 1-1 rpc communications like voice/video while keeping enclave and conversation with offline forward secrecy with our current system

Anyway, for now, no need to continue in the nacl way, as we plan to launch publicly with only the base features; it will be easier to have external feedbacks as soon as we are public and open source

Thanks again