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