This approach has several weaknesses:

• ECB mode can very easily lead to data exposure if multiple messages are encrypted with the same key, or if a single message spans multiple blocks; use CBC or GCM mode, and a unique random IV for each message (to be transmitted along with the ciphertext)
• Using SHA256 as a key derivation function (KDF) provides very little protection against brute-force attacks to recover the password; use a proven KDF, or a secure random key

Instead of building an encryption scheme from primitives, consider using high-level API such as JWE or Plug.Crypto (https://hex.pm/packages/plug_crypto)

I have been tinkering with a requirement to encrypt some data before storing in a database. Now I am extremely new to a lot of this and in all fairness my need is very small, but I found a lot of good references with the following that certainly helped: https://github.com/dwyl/phoenix-ecto-encryption-example.

Most likely it doesn’t fit your requirements, but just in case

An AES key must be 16 bytes long. Payload must be a in blocks of even 16 bytes but if using aes_ecb you should not encrypt more than 1 block (16 bytes). It is not secure to do so.

If using another crypto mode, such as aes_cbc you must pad it so that the payload is evenly divided by the block size but if you pad you must authenticate the crypto otherwise it is not secure. (See padding oracle)

And if you authenticate the crypto please make sure that you use a constant time compare when checking the authentication otherwise this can be utilized to crack the crypto.

Alternatively use a crypto with authentication such as AES-GCM.

EDIT:

I’ve had a look at the AES_ENCRYPT in MySQl (which I assume you are using?). They do pad the string but they don’t mention which padding algorithm, iv or what type of aes mode they are using but from some stackoverflow post it seems like they are using AES-ECB, padded with PKCS#5.

This approach does not really offer any benefits over symmetrical crypto, and will have significant performance impact.

The fact that the key stored in the Radius configuration files is notionally the “public” half of the key pair does not change the fact that anyone who has access to the plaintext config file will be able to decrypt all passwords. The fact that the “private” half is kept more secure just means someone with only the public key can’t encrypt new passwords, which presumably isn’t what you are concerned about.

Thanks for all the input

Though we decided against aes just now, I came up with the following solution to the mysql implementation of aes_ecb as a personal challenge, which works well in my test cases:

#
# Encrypt password with 128-bit aes and insert into database as hex value
#
@aes_blocksize 16

def encrypt(data, key) do
  :crypto.block_encrypt(
    :aes_ecb,
    mysql_key_pad(key),
    pkcs7_pad(data, @aes_block_size)
  )
  |> Base.encode16()
end

# PKCS7 Padding
defp pkcs7_pad(data, blocksize) do
  pad = blocksize - rem(byte_size(data), blocksize)
  data <> to_string(List.duplicate(pad, pad))
end

defp mysql_key_pad(key) when byte_size(key) < @aes_block_size do
  bits = 8 * (@aes_block_size - byte_size(key))
  key <> <<0 :: size(bits)>>
end

defp mysql_key_pad(key) when byte_size(key) == @aes_block_size do
  key |> :binary.bin_to_list()
end

defp mysql_key_pad (key) do
  bytelist = :binary.bin_to_list(key)
  bytes_to_pad = (@aes_block_size - rem(length(bytelist), @aes_block_size))

  bytelist ++ List.duplicate(<<0::8>>, bytes_to_pad)
  |> Enum.chunk_every(@aes_block_size)
  |> Enum.reduce(
      List.duplicate(<<0::8>>, @aes_block_size),
        fn chunk, acc ->
          :crypto.exor(acc, chunk)
        end
    )
end

You can also implement the functionality of :crypto.exor(acc, chunk) in Elixir with a recursive function like
do_xor_calculation(chunk1, chunk2, accumulator), as I did first, but with :crypto.exor/2 it is way more comfortable.