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 (plug_crypto | Hex)

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: GitHub - dwyl/phoenix-ecto-encryption-example: 🔐 A detailed example for how to encrypt data in an Elixir (Phoenix v1.7) App before inserting into a database using Ecto Types · GitHub.

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.