Incorrect key size in PHP mcrypt when porting CryptoPP AES encryption to PHP's mcrypt

Question

Earlier I managed to port some C++ CryptoPP Rijndael_128 CBC code to MCrypt PHP, but now I'm having problems with CFB mode. The C++ and PHP results do not match (well the first byte matches but this could be coincidence, everything else doesn't). With some diagnostics, it looks like PHP's mcrypt is not setting the key length correctly?

Here's the C++ (diagnostics and sundries removed for simplicity):

CryptoPP::CFB_Mode<CryptoPP::AES>::Encryption encryptor(g_encrypt_key, CryptoPP::AES::DEFAULT_KEYLENGTH, g_encrypt_iv);

//  CryptoPP::AES::DEFAULT_KEYLENGTH has the value of 16

// The HexEncoder is being used for debugging purposes, product code uses Base32

CryptoPP::StringSource( sInput.c_str(), true, 
        new CryptoPP::StreamTransformationFilter( encryptor, 
        new CryptoPP::HexEncoder( new CryptoPP::StringSink( sEncryptedOut ) )
        )
        );

And here's the PHP:

  $cipher = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CFB, '');
  mcrypt_generic_init($cipher, $g_encrypt_key, $g_encrypt_iv);
  $sEncryptedOutput = mcrypt_generic( $cipher, $sInput);
  mcrypt_generic_deinit($cipher);
  mcrypt_module_close($cipher);

g_encrypt_key and g_encrypt_iv are both 16 bytes long, and the bytes match for the C++ and PHP versions. For the PHP version it is a binary string constructed from the bytes (yes I have checked these are identical).

I have added calls to the PHP version to check $cipher's block size, key size, etc. The block size and iv size are both 16; supported key sizes are reported as 16, 24, and 32 - all as expected.

Where I think the problem is, is that the keysize is being reported as 32 bytes. Looking at the mcrypt docs, the only way of setting the keysize is by supplying a key of the required size. But I'm passing a 16 byte key! So why is it reporting the presence of a 32 byte key? If CFB mode must use a 32 byte key, then why does CryptoPP accept it as okay? What is the solution? Can I force PHP to use the 16 byte key that has been provided? Or is there a parameter that I'm missing which is defaulting to a different setting in CryptoPP than in MCrypt?

I am using the CFB mode because I want to minimize the length of the resulting encrypted data. The few bytes that padding would introduce, do matter in this application.

I need to be able to encrypt/decrypt in C++ but only encrypt in PHP. AES is arguably overkill for my application - the minimum I need is "a good scrambling of the bytes" so that the function of individual bytes in the data are not obvious.

Answer 1

It's been awhile, but I had some similar problems with mcrypt and openSSL using CFB a couple years ago. In the end, I discovered mcrypt used a different default feedback chain size than openssl in CFB mode. That is to say, I believe an openSSL AES128 in CFB used a block size and feedback size of 128 bits, while mcrypt used a block size of 128bits and a feedback size of 8 bits. I have no way to confirm this, it was just speculation at the time based on reading some old forum posts. Regardless of the truth of that theory, I was not the only person or first to have this particular issue.

The solution for me was to use nOFB as yourself. According to the PHP mcrypt library reference MCRYPT_MODE_NOFB forces the feedback-chain to equal the algorithm's block size, in this case a 128bit block/feedback for AES128 (Rijndael), which matches with what the manpage for the mcrypt module states about nOFB. This is good as everything I found said nOFB feedback is synchronous to the block size. Thus, both mcrypt and OpenSSL in nOFB were now 128 bit key/iv/block/feedback sizes for AES128 and everything worked fine.

As far as PHP reporting 256bit keysizes (32 bytes), the function that returns the current cipher-algorithm key size actually returns the maximum key size, which isn't clearly stated in the documentation. I know this because my little class I use all the time now for various projects works perfectly fine with openSSL and any other AES libraries in CBC or nOFB . This wouldn't be the case if mcrypt was padding my 128bit(16 char) key with an additional 128bits of null string, or whatever, and wouldn't be technically correct anyhow.

Not really a good answer, but the best I got based on a very amateurish foray into cryptography several years ago.