Porting one function from php to elixir

Looks like this will handle RIJNDAEL_256 cyphers: elixir-mcrypt/lib/mcrypt.ex at master · system76/elixir-mcrypt · GitHub, Its 6 years old though, probably only built to handle some forward porting of old code. It may still work it may not.

Poking around it seems that MCRYPT_RIJNDAEL_256 is a non-standard crypto block size/method, I would not try to implement it in newer code.

If you’re working with an existing dataset, porting that to an Elixir application, I would consider decrypting it, then re-encrypting in Elixir with something in the elixir/erlang crypto package (:crypto or maybe GitHub - ntrepid8/ex_crypto: Wrapper around the Erlang crypto module for Elixir. · GitHub (not used myself)). This depends on how sensitive your data is though, transport method, etc etc, you will know if this matters or not.

If you’re just starting a new project and want to encrypted things then I would look for Elixir specific tutorials (Maybe this? Building an Elixir Encryption Engine with Erlang's Crypto Module).

I tried a couple of combination while on a coffee break, but couldn’t find the right one, but I’ll leave here some hints that still may help:

• (nope) RIJNDAEL_256 in MODE_ECB should map to :aes_256_ecb AFAIK ← I was wrong, it is a variation, so this post is wrong! Sorry for that, I have been misleaded by poor research
• ECB is a block cipher, so output should be unpadded after decryption. However, afaik mcrypt uses a %00 padding (source) that should be easy to spot
• key in the example is 192 bits, so I suppose mcrypt is padding it too. I cannot find evidence of this, however (I find instead occurrences of helper functions to pad the key manually on github), so this kinda smells to me

Hope there is some useful hint here, working with crypto stuff is always an adventure! Will try again alter maybe, but let us know if you find a correct translation in the meantime!

According this issue block encoding does not work, so I didn’t even check that

I also can’t change the encryption method or decrypt/re-encrypt existing data because data that was encrypted with this cypher is a cookies data, eventually we going to do that, but this will take about 3 months to propagate, I would like to test elixir a lot sooner

I will post a solution if I find one

If it is a cookie, is it not acceptable to lose the current data and start with a new algorithm in PHP and Elixir?

Unfortunately I cannot lose this data

Pass-through to a PHP “”“micro service”“” to decode the cookie and pass it back to Elixir to re-negotiate. Probably what I’d do if pressed and really wanted to get the elixir app into production.

Depends on your timeline, if 3 months is the cutoff, and you wont be in prod before then, just patch the PHP to transform them into reasonable cookies now and not worry about it later?

The PHP code is probably like 10 lines to catch a POST, hit mcrypt and send the response? You only have to hit it once per cookie over that 3 month window, so any performance penalty is probably slim. Run your internal request over HTTPS and it’s still reasonably secure?

It’s an idea anyway.

Exactly, if you cannot lose this data then you have to convert to a new encrytption algorithm with PHP and start deploying elixir not before three months. This is the safe way.

Hopefully you will find a way to do the conversion in Elixir directly.

I’d probably just embed a small php script in the elixir project and drive it with System.cmd or a port to encode data to something elixir understands and then reencode in a format more suited to elixir. Add some metric collection to see how often the fallback to php is actually needed and once it’s low enough you can pull the php script from use.

Yes, this is the way. Forgot you can just use php directly without other interface. This is pretty easy to deploy and manage while keeping your green fields … greenish.