I completely get what you mean @vegabook. I too struggled longer than I’d like to admit before I got my assymetric RSA encryption working. Please see below for a module I wrote, that hopefully explains things well enough.

defmodule Ls.Crypto.Assymetric do
  @moduledoc """
  Functionality releated to assymetric encryption, e.g. public key encryption.

  Create the keys used here in the following way:

  # Public key.
  openssl genrsa -out private.pem 2048

  # Private key.
  openssl rsa -in private.pem -pubout -out public.pem
  """
  @encrypt_decrypt_opts [rsa_padding: :rsa_pkcs1_oaep_padding]

  def encrypt_rsa(text, key_path) do
    key = load_key(key_path, :RSAPublicKey)
    :public_key.encrypt_public(text, key, @encrypt_decrypt_opts)
  end

  def decrypt_rsa(cipher_text, key_path) do
    key = load_key(key_path, :RSAPrivateKey)
    :public_key.decrypt_private(cipher_text, key, @encrypt_decrypt_opts)
  end

  defp load_key(key_path, expected_key_type) do
    {:ok, raw_key} = File.read(key_path)

    [enc_key] = :public_key.pem_decode(raw_key)
    pem_entry = :public_key.pem_entry_decode(enc_key)

    # Check that we loaded a key that's of the expected type (private vs public).
    # It's an easy mistake to load the wrong key, so this check can
    # save a lot of debugging time.
    if elem(pem_entry, 0) != expected_key_type do
        raise("Expected a key of type #{expected_key_type}, got #{elem(pem_entry, 0)}")
    end      

    pem_entry
  end
end

Caveats

1. A .pem file is a container format, so it can contain many different things. This is why we need to do the :public_key.pem_decode/1 and :public_key.pem_entry_decode/1. My code assumes the PEM file contains just a single key.

2. It works on my machine and for my particular use case. It’s definitely not the most general, universally applicable way of doing things .

It’s a thing of beauty!

image1200×766 133 KB

I had the exact “fun” you’re talking about. Crypto is really interesting, deep and complex. Learning more about how any part of it works is well worth the effort (or rabbit hole). Good luck!

That sounds like a great idea @vegabook! Using something standardized / well thought out that someone else spent a lot of time thinking about is almost always the way to go. It’s way too easy to miss out on some subtleties otherwise, especially when it comes to security and cryptography.

Like @danj wisely pointed out - using asymmetric encryption limits your data to approx. the size of the key. If you want to send more data you need to mix in symmetric encryption (e.g. AES) as well and encrypt the AES key using RSA. Suddenly you need to make sure you don’t make yourself vulnerable to silly things like the two-time-pad attack etc etc. TL;DR - it gets hairy very quickly! I don’t even know this stuff particularly well, just well enough to be dangerous .

I was re-reading your original question a bit more properly just now…

If what you really want it a secure and authenticated websocket link between Python and Elixir…I’m thinking about it like this.

• A websocket connection always starts out with a normal HTTP connection that then gets UPGRADEd to a websocket connection.
• HTTPS has pretty solid security built in. Could you perhaps simply use server + client certificates, and make sure you use HTTPS / WSS connections. This way the HTTPS/Websocket libraries you use should take care of all the heavy lifting when it comes to securing the connection, and authenticating the user.
• I don’t really know your use case that well, so this idea might make no sense at all

If you’re not completely married to the idea of websockets, but still need bidirectional communications, then there’s always the option of going with something like Postgres listen/notify (pubsub), Redis Pubsub or something like ZeroMQ.

If you want something more “ready made” and opinionated it might also make sense to look at gRPC or Thrift. They’re creates specifically for cross-language function calls, and they can come in very handy at times.

If you don’t even need the bidirectional bit then good ol HTTPS with client & server certificates probably makes a lot of sense.

Ah you’re interactiving with Bloomberg over the internet - gotcha!

Cool that you used ZeroMQ before. I only suggested it because most people I know never heard of it, and much less used it .

But you’re 100% right - it won’t be a good solution in this case. Seems like you have a pretty good plan on how to do it. Good luck, hope it works out great!