mcrypt_encrypt to openssl_encrypt, and OPENSSL_ZERO_PADDING problems

Question

I have this mcrypt_encrypt call, for a given $key, $message and $iv:

$string = mcrypt_encrypt(MCRYPT_3DES, $key, $message, MCRYPT_MODE_CBC, $iv);

I'd like to change the mcrypt_encrypt call to an openssl_encrypt one, to future-proof this.

By having $mode = 'des-ede3-cbc' or $mode = '3DES'; and $options = true I get the more similar response, but not identical. Is there other way to call it to get a perfect match?

I'm getting this (base64_encoded) for a lorem-ipsum $message+$key combinations, so I'm starting to believe one function or the other are padding somewhat the message before encrypting...

for mcrypt

"Y+JgMBdfI7ZYY3M9lJXCtb5Vgu+rWvLBfjug2GLX7uo="

for for openssl

"Y+JgMBdfI7ZYY3M9lJXCtb5Vgu+rWvLBvte4swdttHY="

Tried using $options to pass OPENSSL_ZERO_PADDING, but passing anything but 1 (OPENSSL_RAW_DATA, or true) results in an empty string...

Neither using OPENSSL_ZERO_PADDING nor OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING work... :( I'm using "OpenSSL 1.0.2g 1 Mar 2016".

Already read this q&a, but it doesn't help me. Not the only one with padding troubles, but no solution in sight so far. (Second answer talks about adding padding to mcrypt call, I would really want to remove padding from openssl encryption call...

You should never get a perfect match, EVER. That's what initialization vector is for. Every time you encrypt the same payload with the same algorithm and the same key, you should get completely different output if you want to be safe. If you get the same output for same input, your encryption is weak. That's the point of IV in encryption. Once encrypted, you deliver encrypted payload with IV to the other side. — Mjh
If I'm using the same payload, same algo, same IV; I reckon I should be getting the same output. Never mind that that I should use a different IV for each call: using the same IV for both calls (mcrypt and openssl), I think I should get the same output, right? I'm starting to believe is related to message padding, since the begging of the output is the same. — yivi
If everything is the same then you should be getting the same output, correct. 4th parameter for openssl_encrypt controls the padding. You can encrypt with $encrypted = openssl_encrypt($data, $alg, $key, OPENSSL_ZERO_PADDING, $iv); and check if you get the same output. At www.php.net/openssl_encrypt, you can read the comments to see how to use 4th parameter. — Mjh
OPENSSL_ZERO_PADDING doesn't work, at least for me ... but yes - padding is why you can't get the same result. However, there's so many thinks wrong with your encryption scheme, that you might as well just replace it with a new one - please use a library for that, don't roll your own. — Narf
Right now is about to understand how to make this call and get the same results than with mcrypt.Thanks for your comments on encryption. This is neither the full solution, nor I have the authority to change everything I'd want in this codebase. — yivi

Joe Joe · Accepted Answer · 2017-01-16T13:00:27

mcrypt_encrypt zero-pads input data if it's not a multiple of the blocksize. This leads to ambiguous results if the data itself has trailing zeroes. Apparently OpenSSL doesn't allow you to use zero padding in this case, which explains the false return value.

You can circumvent this by adding the padding manually.

$message = "Lorem ipsum";
$key = "123456789012345678901234";
$iv = "12345678";

$message_padded = $message;
if (strlen($message_padded) % 8) {
    $message_padded = str_pad($message_padded,
        strlen($message_padded) + 8 - strlen($message_padded) % 8, "\0");
}
$encrypted_mcrypt = mcrypt_encrypt(MCRYPT_3DES, $key,
    $message, MCRYPT_MODE_CBC, $iv);
$encrypted_openssl = openssl_encrypt($message_padded, "DES-EDE3-CBC", 
    $key, OPENSSL_RAW_DATA | OPENSSL_NO_PADDING, $iv);

printf("%s => %s\n", bin2hex($message), bin2hex($encrypted_mcrypt));
printf("%s => %s\n", bin2hex($message_padded), bin2hex($encrypted_openssl));

This prints both as equal.

4c6f72656d20697073756d => c6fed0af15d494e485af3597ad628cec
4c6f72656d20697073756d0000000000 => c6fed0af15d494e485af3597ad628cec

mcrypt_encrypt to openssl_encrypt, and OPENSSL_ZERO_PADDING problems

2 Answers