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).

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.

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.