A PHP application I'm maintaining uses Rijndael_256 with EBC_MODE encryption with mcrypt. Fun has it that the key isn't 256 bits long, but only 160. According to the mcrypt_encrypt documentation the key is padded with \0 to get the required size if it's too small.
The key with which the data will be encrypted. If it's smaller than the required keysize, it is padded with '\0'. It is better not to use ASCII strings for keys.
This seem to happen at around the start of line 1186 in mcrypt.c and modifying the key at line 1213.
So lets say we've got $key = 'abcdefghijkm'; which is too short, but PHP's implementation of mcrypt makes sure it's extended to 32 characters (or 256 bit) when using RIJNDAEL_256. What will the final key look like?
I'm asking this because another application is being built that uses the same encrypted data, but is in another language. Perl to be exact and I'm using Crypto::Rijndael. For the given example key, what is the exact key I would have to feed to Crypto::Rijndael (or any other for that matter) to be able to decrypt the data again?
Update
With Perl I can generate a key that's \0 padded doing pack('a32', 'my secret key'); (or Z32), length() will report 32 and the Crypt::Rijndael module accepts the key. Looking at the source of PHP's mcrypt this should be the key that's being generated (\0 padded), but it simply won't take it.
In theory in PHP pack('a32', 'my secret key'); should result in the same \0 padded key that PHP's mcrypt generates, but this isn't the case.
I'm very close to just encrypt everything again but with a new key. This is taking too much time.
