Changing the BUFSIZE had no effect on Solaris, it still crashed in RSA_free(). It complained about insufficient seed size, so I added a RAND_seed(). Now I don't need that any more. Amazing how one small problem can have so many side effects! Chris
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte via RT Sent: Monday, June 28, 2004 12:34 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #904] Re: Segfault in speed measurements with aes ecb decrypt Good. I also discovered that with this change, there was no need to have an increased BUFSIZE any more. The changes will be visible in tomorrow's snapshot. Ticket resolved. [EMAIL PROTECTED] - Mon Jun 28 18:00:56 2004]: > With your patch, the speed command now works fine on my Solaris build of > 0.9.7d (compiled using cc). > Chris Brook > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte via > RT > Sent: Monday, June 28, 2004 8:51 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [openssl.org #904] Re: Segfault in speed measurements with aes > ecb decrypt > > > > A followup: > > [levitte - Mon Jun 28 14:33:57 2004]: > > > > 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. > > Please try the following patch, which did fix it for me: > > Index: apps/speed.c > =================================================================== > RCS file: /e/openssl/cvs/openssl/apps/speed.c,v > retrieving revision 1.83.2.17 > diff -u -r1.83.2.17 speed.c > --- apps/speed.c 28 Jun 2004 12:23:40 -0000 1.83.2.17 > +++ apps/speed.c 28 Jun 2004 12:49:24 -0000 > @@ -1399,6 +1399,7 @@ > > EVP_DecryptInit_ex(&ctx,evp_cipher,NULL,key16,iv); > else > > EVP_EncryptInit_ex(&ctx,evp_cipher,NULL,key16,iv); > + EVP_CIPHER_CTX_set_padding(&ctx, 0); > > Time_F(START); > if(decrypt) > > > -- > Richard Levitte > [EMAIL PROTECTED] > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > -- Richard Levitte [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
