I like crypto! And I like puzzles, and I had a suspicion Node was doing something silly, so I chased this a bit. I’ll say two things right off the bat:
First, this would be confusing to anyone. Node made some choices that favored ease of use, and sacrificed clarity (and security!) in the process. Node is doing things hidden from you that you couldn’t possibly have known about without knowing exactly what to search for. With a little experience with cryptography concepts it’s not bad, but if you’re new to this stuff (and you mentioned you are) this is really hard to solve without help.
Second, @hauleth is right that a revamp of how you encrypt things is warranted, but we don’t always have the luxury of doing that with legacy data! Best practices here do not solve the problem in front of you. For what it’s worth, I don’t think you’re encrypting in ECB in Node, I think you’re actually using CBC.
With all that said, to make any progress there are some things to figure out before we can decrypt the data Node is producing in Elixir.
Question 1: what block cipher mode is Node using?
You specified aes256 in your JS code and aes_256_ecb in Elixir. The string “aes256” doesn’t really tell us the whole story, because encryption is not just about which encryption algorithm is being used, it’s also about how each block of data is operated on during the encryption or decryption process. You’ve selected “ECB” (electronic code book) but there are others, like “CBC” (cipher block chaining). You really need to know which one is being used if you want to decrypt your data.
If you head down the rabbit hole far enough with the Node docs you’ll see that aes256 value you’re passing is from a list of ciphers provided by OpenSSL. Unfortunately, the string aes256 doesn’t tell us the block mode.
I couldn’t find a clear explanation of what aes256 truly maps to so I just ran openssl enc -aes256 to see what would happen. The first thing you’ll see is
enter aes-256-cbc encryption password:
So, that makes me think when you say “aes256” in your code in Node it’s really a shortcut for aes-256-cbc.
That means the first thing you have wrong is the algorithm, instead of ECB you should be using :aes_256_cbc.
Question 2: But if it’s CBC, what’s the initialization vector?
This wikipedia page talks a bit about block cipher modes. The primary thing to notice is the difference between ECB and CBC mode. You could also google other resources explaining block cipher modes that might be more clear than that wikipedia page.
If you look at the pictures describing how ECB works, you’ll see decryption needs two inputs: the key and some ciphertext (aka encrypted data).
You’ll also see that CBC expects three inputs. The key, the ciphertext, and something called an “initialization vector” (IV) to get things started.
Since you are (apparently) using CBC but not supplying an IV in your JS code, the only conclusion is that Node is generating an IV for you, and it must be doing it deterministically (not a great thing in the crypto world, one of the reasons the Node docs push people toward createCipheriv).
Luckily you’re not only one dealing with this. Here’s someone trying to solve the same problem in Ruby.
Summarizing the Stack Overflow post above: Node takes the “password” you provide (of any length) and uses that to produce an encryption key and an IV. So it turns out that not only is Node secretely making an IV for you, it’s also creating an encryption key that’s based on your “password” but not literally your password. In your example, the decryption key is not actually “mysecretkey” (no surprise, since it’s too short to be an encryption key!)
That’s all outlined in the Stack Overflow answer I linked to, which I recommend you read.
If we copy what they did in Ruby in Elixir, that process could look something like this:
a = :crypto.hash(:md5, password)
b = :crypto.hash(:md5, a <> password)
c = :crypto.hash(:md5, b <> password)
iv = a <> b
key = c
And finally, encoding
Last but not least, your JS code makes me think that your encrypted data is probably being passed around encoded as base 16 (hex), for example are you providing something like “f07258ace89d16d847cb0ec520b19438” as input when you try to decrypt data?
If so, that means you need to decode the hex string before you try to decrypt it. You can use Base.decode16!(encrypted_text, case: :lower) for this.
Putting it all together
So, if I had to summarize, it’d be this: Node is trying to be helpful by hiding a bunch of things from you, and that works if you never have to decrypt something outside the Node ecosystem, but it’s a crappy design if you do. In their defense, the createCipher function you’re using there has been deprecated in favor of a function that takes a true key (not a “password”) and an explicit IV value (you must generate it, they will not do it for you). I’m very happy they’ve deprecated the function you’re using.
The good news is you can definitely re-create what Node did behind the scenes so that you can decrypt your data in Elixir.
First, here’s an example of some JS code that I’m guessing is close to your own. We can use it to generate test data.
const crypto = require('crypto')
function decryptString(key, encryptedString) {
const algorithm = 'aes256';
const decipher = crypto.createDecipher(algorithm, key);
return decipher.update(encryptedString, 'hex', 'utf8') +
decipher.final('utf8');
}
function encryptString(key, plaintext) {
const algorithm = 'aes256';
const encipher = crypto.createCipher(algorithm, key);
const encrypted = Buffer.concat([encipher.update(plaintext), encipher.final()]);
return encrypted.toString("hex")
}
const password = "mysecretkey"
const plaintext = "hello world"
console.log("Plaintext: ", plaintext)
console.log("Password: ", password)
var encrypted = encryptString(password, plaintext)
console.log("Encrypted: ", encrypted)
var decrypted = decryptString(password, encrypted)
console.log("Decrypted: ", decrypted)
That produces the following output:
Plaintext: hello world
Password: mysecretkey
Encrypted: 686ca8793bf5e7317cfd451aa81b72cf
Decrypted: hello world
So in Elixir our goal is to decrypt the string “686ca8793bf5e7317cfd451aa81b72cf” by mimicking Node. If we succeed then we know we’ve copied Node’s approach.
# As we discovered earlier, you want CBC:
algo = :aes_256_cbc
# Not literally your encryption key, just a value Node uses to generate a key:
password = "mysecretkey"
# Calling this "encoded" ciphertext because it looks like you're using hex strings:
encoded_ciphertext = "686ca8793bf5e7317cfd451aa81b72cf"
# Your ciphertext hex-decoded
ciphertext = Base.decode16!(encoded_ciphertext, case: :lower)
# Re-creating how Node generates the IV and key values from a "password" string
a = :crypto.hash(:md5, password)
b = :crypto.hash(:md5, a <> password)
c = :crypto.hash(:md5, b <> password)
iv = a <> b
key = c
# Decrypting the data. Notice that we're also specifying the padding so it's stripped.
:crypto.crypto_one_time(algo, iv, key, ciphertext, [encrypt: false, padding: :pkcs_padding])
|> IO.inspect()
That prints out “hello world” on my machine.
I hope that helps you get unstuck and away from Node 
If I had to suggest a new approach once you’re able to migrate off your legacy Node code:
- Use a full randomly generated key, don’t generate one like Node does based on a short “password” string
- Don’t feel tempted to use
aes_256_ecb because it’s easier. Something like aes_256_cbc is fine as far as I know, and there are others.
- Erlang’s built-in crypto stuff is, to my knowledge, perfectly fine to use
- We didn’t find Cloak’s abstraction particularly useful, but it’s possible you might, certainly worth reading up on it once you get there.
I know it is true for most domains but in that case it is almost overwhelming.
