Hi,

> I was absolutely sure that parameters of all AES functions are
> equivalent in all implementations.

First of all you have to recognize that aesni_*, vpaes_* and alike are
*private* interfaces. Private to EVP and therefore have to fulfill only
EVP's requirements.

> However, I found that
> AES_cbc_encrypt and aesni_cbc_encrypt differ in length parameter if it's
> not a multiple of 16. For example,
> AES_cbc_encrypt (in, out, 15, ... ) is returning 15 bytes in out buffer,
> but
> aesni_cbc_encrypt (in, out, 15, ...) is returning only 1 byte.

What does "return 15 or 1 byte" mean? AES is block cipher and both
functions (even though aesni_cbc_encrypt formally doesn't have to)
always write 16*n bytes, rounded upwards. If input length is not
divisible by 16, then data is padded with zeros and last 16 bytes are
written, and it's always 16 bytes.

> I looked into the aesni-x86.pl code, and found the strange lines:
>     &mov    ("ecx",16);        # zero tail
>     &sub    ("ecx",$len);

This is above mentioned padding. In above example up to this point it
copied 15 bytes to temporary buffer and then, past the line in question,
zeros 16-15=1 bytes. Therefore ecx=16, ecx-=$len. One can argue that it
shouldn't handle it this way, but it does it as tribute to other CBC
implementations in OpenSSL. They *all* are quirky in this way. If
expectation is that output should be of same length, then plain CBC is
not the mode for the target application. One can deploy ciphertext
stealing, one can argue that it, ciphertext stealing, should be
implemented in EVP, but one can't expect output of same length (for
lengths not divisible by block size) from AES_cbc_encrypt.

> That's why the output length is always (16-len). I'm not sure this is a
> bug, but I can't find a good reason why the length is changed here.
> By the way, vpaes routines can't accept length if it's not a multiple of
> 16 at all.

Correct, and aesni could do the same. The only reason for why aeni is
different from vpaes is because *initially* it was developed with option
to produce exact drop-in replacement for aes-586.pl in mind. vpaes was
developed for usage from EVP only and therefore can expect that input
length is always divisible by 16.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to