[EMAIL PROTECTED] - Sun Jun 27 15:30:32 2004]: > Yes, increasing the buffer size fixes this.
I just committed the BUFSIZE fix, with some comments explaining why it needs to have a larger size than the largest number in lengths. > At the end of the encryption process (in EVP_EncryptFinal_ex()) when the last > block is not fully used the rest of the buffer ctx->buf is filled with the > number of remaining (unused) bytes. This value is later on extracted during > decryption in EVP_DecryptFinal_ex(). If only decryption is used, then the > rest of the buffer is not filled with the padding value, hence the error > messages. > > This can be fixed as follows: buf_len is always = 0 when the message length is > a multiple of the block size. Therefore we need to test when decrypting the > final block whether buf_len = 0. If so, we can not take the number we have > left from the rest of the block as the block is full. The number we have left > is zero then (See patch attached). Your patch is flawed. At that point, there has been a test to check if ctx->buf_len is non-zero already, and an error is generated if it is. At the point of your patch, ctx->buf_len will *always* be zero. I think the real problem lies in apps/speed.c, which should set the EVP_CIPH_NO_PADDING flag for the decrypt tests (at the very least). The speed difference will be very small. -- Richard Levitte [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
