> Subject: [openssl.org &3182] Bug in OpenSSL 1.0.1e 586 assembly optimized > AES_cbc_encrypt > From: r...@openssl.org > To: cosborn...@hotmail.com > CC: openssl-dev@openssl.org > Date: Wed, 27 Nov 2013 15:33:08 +0100 > > On Tue Nov 26 22:30:34 2013, cosborn...@hotmail.com wrote: >> I've noticed what appears to be a bug in the 586 assembly-optimized >> AES_cbc_encrypt function of OpenSSL 1.0.1e, (compiled on Windows) >> when encrypting data that is> 1 block in length, but not an >> integral multiple of the block size. > > Well the low level cbc routines behaviour when the input is not a multiple of > the block size is undefined. The higher level EVP routines pad the input data > to a multiple of the blocks size if block padding is not disabled. If block > padding is disabled then attempting to encrypt data whose total length is not > a > multiple of the block size returns an error. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org >
I don't seem to be able to find any documentation indicating that this is undefined behavior, however documentation for the near identical method DES_ncbc_encrypt states: "If the length argument is not an integral multiple of <block size> bytes, the last block is copied to a temporary area and zero filled. The output is always an integral multiple of <block size> bytes." It seems reasonable to assume a consistent API, and any ambiguity should be resolved by referring to the C source, which appears to confirm that partial blocks are indeed zero-padded. CO ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
