CryptoAPI AES without expanding the buffer size for cyphertext

Hello,

I have a CryptoAPI based project where it is necessary for AES encrypted
cyphertext to fit within the same space as the original plaintext.  I am
using AES-128 with CBC.  As you know, CryptEncrypt with a symetric key and
CBC expands the size of the ciphertext by up to one block size.

Is there a way to work around this requirement without losing the benefit of
CBC and remain FIPS 140-2 compliant?

Gandalf

Not to my knowledge. (I checked my Wincrypt.

Not to my knowledge. (I checked my Wincrypt.h file and in addition to
PKCS5_PADDING there are only random and zero paddings. I do not see "no
padding" option.)

You can work around this limitation (with some but not much added code and
32 bytes of stack space) simply by saving the last 16 bytes into a local byte
array, do the rest of the AES operation in the chopped area (ignoring the
last 16 bytes) the do the last 16 bytes CBC on the copied last block and copy
back the encrypted / decrypted block into the original last 16 bytes area.

Alternatively, you can use other crypto libraries (Cryptoki = PKCS#11 or
OpenSSL).

Laszlo Elteto
SafeNet, Inc.

I think it is not either possible with other crypto libraries, as AES is

I think it is not either possible with other crypto libraries, as AES is a
block-based algorithm.

Certainly it is possible if the input length is exact multiple of the

Certainly it is possible if the input length is exact multiple of the block
size.

Laszlo Elteto
SafeNet, Inc.

For CBC with other input lengths, there are "ciphertext stealing"and "residual

For CBC with other input lengths, there are "ciphertext stealing"
and "residual block termination" schemes that do not expand the
data, but I do not know if FIPS 140-2 allows those.

The original question was obviously not about modes where by definition

The original question was obviously not about modes where by definition the
output length is always the same as the input length (like Counter mode). And
anyway MS CAPI supports only a few specific modes.

Laszlo Elteto
SafeNet, Inc.