Maybe I shouldn’t revive this topic (in that case, sorry!), but I believe figuring out ways to make it easier to implement encryption in Elixir and Phoenix applications is more relevant, and pertinent, than ever.

The following library is a good choice to use if attempting to implement encryption in your Elixir/Phoenix applications:

• enacl - provides libsodium bindings

Sodium (libsodium) is a fork of NaCl, a trusted library by security experts. By using enacl (libsodium/NaCl) you set yourself up to not accidentally make a mistake that renders your security not as secure as you think. The PragProg book, Practical Security, also recommends the library for encryption for this very reason.

Additionally, this is an interesting take by Badu on implementing both symmetric encryption and asymmetric encryption (along with user derived keys).

Symmetric Encryption
In regard to symmetric encryption, dwyl made a great Phoenix encryption example that I’ve been testing and works exceptionally well from a developer and client perspective.

It is worth noting however, that the person (or company/people) with access to the encryption keys can theoretically decrypt the data. This is true of all symmetric encryption.

Asymmetric Encryption
Badu has two nice examples here with Elixir, Part III and Part IV.

Asymmetric encryption is commonly referred to as public-key cryptography. I don’t know of any other example in Elixir/Phoenix other than Badu’s.

End-to-End Encryption (E2EE)
The Signal Protocol set the bar here. Good news is that the IETF has a working group (MLS) developing a Messaging Layer Security architecture and protocol standard. In theory, it’ll be an excellent choice for anyone working to implement end-to-end encryption (especially for large groups).

I’ve been following their development: MLS GitHub, Datatracker.

E2EE tends to use combinations of asymmetric and symmetric encryption to make it all work.

I’m not aware of any current example offering end-to-end encryption with a Phoenix app. My initial thinking is that you can take guidance from Badu’s asymmetric encryption example and dwyl’s transparent symmetric encryption example to essentially create an end-to-end encrypted Phoenix app. It would work something like this:

• password derived key → gives each person/user access to their data
  Since the password is hashed, only knowledge of someone’s password can ever decrypt their data. This ensures the company/person with access to the system cannot access a client’s key to decrypt their data (in theory).

• transparently shared public keys → gives people the ability to share/edit data with each other
  This would work behind the scenes, transparently to the client, like how dwyl’s example works.

This is clearly not a finished thought, but the idea being that there may be a way to take a symmetric encryption example and combine it with Badu’s asymmetric example to deliver something close to end-to-end encryption in a Phoenix and Elixir app.

Other approaches
For instance, if you’re implementing video chat through Phoenix, over WebSockets, with authentication, using a peer-to-peer mesh architecture and STUN server, then your video chat is already end-to-end encrypted and avoids some of the known WebSocket security vulnerabilities.

I was able to achieve this by following the incredible guide by Jesse Herrick of Littlelines, then tying it into an existing authentication solution (phx_gen_auth for example).

This makes me think that, as mentioned 4 years ago, communication over channels would also be secured similarly provided you setup your Phoenix socket configuration to use :websocket and not :longpoll.

Phoenix has HTTPS and WSS support builtin, see http://www.phoenixframework.org/docs/configuration-for-ssl

For PFS I believe you need to configure your server to use specific key exchange algorithms (i.e. it’s not a matter of the certificate). I don’t know how to do that with Phoenix. Personally I terminate TLS with Nginx and proxy it to Phoenix.

HTTPS and WSS are end-to-end encrypted, one end being the client’s browser and the other end being the server.

For free certificates, take a look at https://letsencrypt.org/

There are many different algorithms that are used for very different reasons.

Diffie-Helmann (which is indeed what DH stands for) lets two parties compute a shared secret. It does not do encryption/decryption itself, that’s just not what it is for. Indeed, usually DH is used to find a shared key, which is then used as encryption/decryption key in a symmetric cypher, such as AES or Blowfish.

ArrayBuffers are things that were added to JavaScript to allow easier (more efficient and less error-prone) manipulations of binary data. I am not entirely sure if the HTML5 WebSocket API (regardless of Phoenix) supports transferring such an object directly; it could very well be that it needs to be converted to either a binary file or a Base64 string.