2

I have an API that requires me to encode data that I send to it through an AES-cipher.

However, the only example code I have been given is Node.js code.

I thought, how hard can it be to reimplement it in PHP as well ?

Pretty hard apparently.

Below you can see both approaches, yet you can also see different results.

Anyone an idea what might be going wrong ?

NODE.js version

var crypto = require('crypto');
var algorithm = 'aes-128-ctr';

function encrypt(text, password) {
  const key = Buffer.from(password, "hex").slice(0, 16);
  const ivBuffer = Buffer.alloc(16);
  const cipher = crypto.createCipheriv(algorithm, key, ivBuffer);
  let crypted = cipher.update(text, "utf8", 'hex');
  crypted += cipher.final('hex');
  console.log(crypted);
}

encrypt('test','ed8f68b144f94c30b8add43276f0fa14');

RESULT : 3522ca23

PHP version

function encrypt($text, $password) {
  $iv = "0000000000000000";
  $encrypted = openssl_encrypt($text, 'aes-128-ctr', $password, OPENSSL_RAW_DATA, $iv);
  return bin2hex($encrypted);
}

echo encrypt('test', 'ed8f68b144f94c30b8add43276f0fa14');

RESULT: 8faa39d2

Community
  • 1
  • 1
oenie
  • 56
  • 1
  • 6
  • 1
    You're using different key and IV. In PHP you're not hex-decoding your key, so it's a 32 byte a-f0-9 string. Also your IV in PHP is 16 zero characters, not 16 zero bytes. – t.m.adam Sep 18 '18 at 13:55
  • While browsing the related section, i already came across a solution that seems to fit your logic. Thanks for replying anyway !! – oenie Sep 18 '18 at 14:21
  • 1
    No problem! You know, you can post an answer, if you think it could be useful to others. – t.m.adam Sep 18 '18 at 14:26
  • I just did, feel free to see if I understood correctly where my mistakes were :) – oenie Sep 18 '18 at 14:45
  • this might help https://stackoverflow.com/questions/41181905/php-mcrypt-encrypt-to-openssl-encrypt-and-openssl-zero-padding-problems – Dnyaneshwar Harer Mar 13 '20 at 14:45

1 Answers1

1

While browsing the related section (after my post) I came across this one: C# and PHP have different AES encryption results

As mentioned by t-m-adam above as well, apparently I need to align the iv and password in both examples. In PHP my iv and password were 'regular' strings, where they should have been binary strings of the same length as the cipher’s block size. My iv should (in my case) be 16 zero bytes instead of 16x the 0 character. You can see the difference by doing an echo of the code below:

$iv = "00000000000000000000000000000000";
echo $iv;
echo strlen($iv);

$iv = pack("H*", "00000000000000000000000000000000");
echo $iv;
echo strlen($iv);

Both $iv variables are of length 16 (as requested by AES) , yet the second version is composed of 0-bytes, effectively unprintable.

Without further ado, the end result, working in PHP:

function encrypt($text, $password) {
  $iv = pack("H*", "00000000000000000000000000000000");
  $password = pack("H*", $password);
  $encrypted = openssl_encrypt($text, 'aes-128-ctr', $inputKey, OPENSSL_RAW_DATA, $iv);
   return bin2hex($encrypted);
}

echo encrypt('test', 'ed8f68b144f94c30b8add43276f0fa14');

RESULT: 3522ca23

Success !!

oenie
  • 56
  • 1
  • 6
  • 1
    Awesome!! If you would like some advice, you could improve your encryption by using a random IV, and an [AEAD](https://en.wikipedia.org/wiki/Authenticated_encryption) algorithm. I've answered a similar question recently, using GCM. You can find it [here](https://stackoverflow.com/a/52263257/7811673) if you want. – t.m.adam Sep 18 '18 at 14:53
  • I'll have to pass that on to the people that implemented the API (a different company). From what I gather from your example (and my intution) this would mean we would have to send the $iv that was used for encryption in the encrypted data itself, to be able to decrypt it, right ? The purpose of that random $iv being less 'crackable' , like a sort of salt ? – oenie Sep 18 '18 at 15:07
  • 1
    Yes, the IV must be unpredictable, but it doesn't have to be secret, you could send it with the ciphertext (and tag if you choose to use authenticated encryption). I can't find any sources, but I think CTR is vulnerable to attacks when IV is reused. – t.m.adam Sep 18 '18 at 15:23
  • 1
    Ok, I found a RFC3686 paper on CTR. See [section 3.1](https://tools.ietf.org/html/rfc3686#section-3.1) for IV and [section 7](https://tools.ietf.org/html/rfc3686#section-7) for security. – t.m.adam Sep 18 '18 at 16:07