Encrypt string with my key

Maybe

message = "i'm almost secure" <> :binary.copy(<<15>>, 15)
password = "your-password"
encrypted = :crypto.block_encrypt(:aes_ecb, :crypto.hash(:sha256, password), message)

Nice, but how I can get encrypted as a string, because I need to send it to my frontend?

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)

And what about if I want to run a bash command inside my app and use stdout, for example I have a command echo 'foo' | openssl aes-256-cbc -a -salt -k one and I got a stdout result what I need, but how I can run this command using System.cmd? I have troubles with that.

Either do it correct and use a Port and send messages to it, or do it one-shot: System.cmd("sh", ["echo 'foo' | openssl aes-256-cbc -a -salt -k one"]) or something…

This improves on the earlier proposal in that it uses CBC, but it still relies on a weak KDF. If you need to use a password (rather than a binary key) you are going to have to bring in a package that implements a strong KDF. You can do the rest with :crypto APIs, no need to shell out to OpenSSL.

Another package that could help is pbcs | Hex, but its documentation is very minimal.

I’m currently struggling to get some similar setup up and running and just don’t get, howto do things.
First and foremost, we don’t do this for server security, but to fulfill GDPR regulations, just to be sure.

We are authenticating PPPoE users by freeradius via CHAP. Basically this means, the customer sends a hash value created from password and a challenge. The radius server has to keep a cleartext password for this to work. For GDPR, we would rather persist the user password aes encrypted. So we now deliver the cleartext password by the SQL query: AES_DECRYPT(UNHEX(value), ‘ThisIsMySecretAesKey’)

So what I try to do is the opposite HEX(AES_ECNRYPT(‘Password’, ‘ThisIsMySecretAesKey’)).

Looking at the (scarce) examples, :aes_ecb boils down to a simple: :crypto.block_encrypt(:aes_ecb, “Key”, “Pass”), but this didn’t work out:

   :crypto.block_encrypt(
     :aes_ecb,
     Application.fetch_env!(:myapp, :aes_key),
     plaintext
   )

Leads to:

** (ArgumentError) argument error
:crypto.block_crypt_nif(:aes_ecb, "Testkey", "Teststring", true)

As this seems to work for several people, maybe someone has some insights, why not in my case.
The above example works, but I assume, padding the strings would not yield the same result with the sql decrypt query?

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.

Ah thanks, I think, MySQL then does this implicitly, while using :crypto, I have to care for this myself.

The real problem is, that (normally), a radius server just awaits a cleartext password from database and in most cases it is realized this way (so, this is more snakeoil to calm our CEOs, security wise ). As far as I know, MySQL does not support ctr based modes, like gcm , so we really seem to be stuck with ecb here.

We could use PAP, with stronger encryption, but unfortunately, PPPoE users would then be forced to send cleartext password while logging in as UDP

Personally, taking into account the possibility, that after an outage, around >20k Users want to log in again as fast as possible, I’d be more comfortable by cleartext password and avoid the encryption overhead for a weak encryption.

EDIT:
That was just my experience. I also di not find a lot of infos, how MySQL does this. ECB was the best, I could get from searching. How the padding is implicitly done is not documented too well.

Yes, you’d have to reverse engineer whatever MySQL is doing. Seems like later versions of MySQL do support different crypto modes (such as cbc).

I just tried and MySQL uses AES-ECB-128 by default. I can decrypt like this:

SELECT HEX(AES_ENCRYPT('testing', '1234567890123456'));
0930A6442C8B22D69A35A30EC032BB73

and then decrypt it in elixir

:crypto.block_decrypt(:aes_ecb, "1234567890123456", Base.decode16!("0930A6442C8B22D69A35A30EC032BB73"))
"testing\t\t\t\t\t\t\t\t\t"

But I don’t know what padding they use if the key is not 16 bytes. Somewhere it is claimed to be 0 padded but I couldn’t get it to work.

All in all, from a security point of view this feels very dodgy. From storing the passwords in the database (instead of a hash, even if encrypted) to the algorithms used.