AES CBC/PKCS7 encryption of empty msg fails

[Marco]

Following C code:

CkCrypt2 c;
c.UnlockComponent(CHILKAT_CRYPT_UNLOCK);
c.put_CryptAlgorithm("aes");
c.put_CipherMode("cbc");
c.put_KeyLength(256);   // key length in bits
c.put_PaddingScheme(0);   // PKCS7 padding

// set key
CkByteData _key;
_key.append2(&key[0], key.size());
c.put_SecretKey(_key);

// set IV
CkByteData _iv;
std::vector<std::uint8_t> rnd_iv(16);
crypt::random::rand(rnd_iv, 16);
_iv.append2(&rnd_iv[0], 16);
c.put_IV(_iv);

// encrypt data
CkByteData _cipher, _plain;
if (plain.size()) {
  _plain.append2(&plain[0], plain.size());
}
if (!c.EncryptBytes(_plain, _cipher)) {
  return false;
}

Problem is, when plain (and _plain) has size zero, returned _cipher has size zero, too.
So it's not possible to encrypt empty messages.
Expected: Padding must pad the first block with 16 x 0x10, XOR it with the IV and return an encrypted 16 byte block.

Is something wrong here?

[Marco]

Is this fixed already?

A possible (valid) AES256-CBC-PKCS7 testvector is:
key: "06a9214036b8a15b512e03d534120006",
iv:  "3dafba429d9eb430b422da802c9fac41",
pt:  "",
ct:  "79bbff7c3e845f5abf59a1f30129d9d4"

[Chilkat]

Thanks Marco,

The testvector you provided is actually for AES128 because the key is 16 bytes.

I updated Chilkat to handle this correctly.  However, for many cipher modes or encryption algorithms it is correct to emit 0 bytes for 0 byte input. (such as for stream ciphers, or cipher modes that effectively turn a block cipher into a stream cipher).

I can provide a pre-release build w/ the fix if you need.  I would need to know the operating system and if Windows, the VC++ version.

[Marco]

Thanks a lot for your offer! I replaced the encryption routines with cryptopp temporarily - which works fine.
I retest this issue with your next release and switch back, when working fine.

Sorry for the confusion with the test vector, of course it's AES128, made a copy/paste error. But the given vector is valid, anyway.

When taking PKCS7 padding, an empty msg is invalid - as far as I interpret the padding spec.

Good to hear that it's working fine now.