-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Richard,

Thanks for taking a look at this! See my comments below.

|
| 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.

Not quite, the test on ctx->buf_len is only done if no-padding is set.
ctx->buf_len is always zero only if the length is a multiple of the block size.


| | 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. |

This looks fine as long as the message is exactly a multiple of the block size,
which is actually the case for speed as the values are hard-coded in speed.c.
However, handling of not-aligned message sizes still remains broken in the speed
test. This is currently not used, but somebody might use it once...

So IMHO your patch fixes the problem in a too restrictive way by only allowing
no-padding - but most people can probably live with that.


| Please try the following patch, which did fix it for me:

It works fine for me except for what I have mentioned above.

- -- Roman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFA4IOA9GOBmbEdi04RAq/TAJ0UCqjq2wVtmju9t5DpmblkgIrX7gCgt3ad
FUctqkOv/O/jVpBSN3+ly1c=
=Of1y
-----END PGP SIGNATURE-----

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to