(Note: this question is completely unrelated to the previous re-keying one, since I've taken out the re-key code for now.)
I have a socket bio to which I'd like to attach an decrypting
bio for reading and encrypting bio for writing. When I attempt
this I get the following error roughly 22% of the time on the
first BIO_read:
BIO_read(bio, buf, 8)
BIO_read returns -1
BIO_should_retry is false
error:0606506D:digital envelope routines:EVP_DecryptFinal:
wrong final block length:evp_enc.c:423:
This is using blowfish with a blocksize of 8 chars, there are actually
at least 24 bytes in the stream, so there's plenty of data for mac
checks.
I ran ethereal to watch the data being sent from the client, and it's
identical, yet 1/5 the time the 'final block length' problem pops up.
One of my concerns initially was that I was going to goof up my prev_bio
and next_bio links by attempting to attach a socket bio to both a
decrypt and encrypt cipher bio. (I always used BIO_push, I never
created the chain manually...)
When I wrote a dinky routine to show the bio chains both forward
(using BIO_next) and backward (reading the prev_bio member directly)
I found that everything looked fine in the 'forward' direction
(cipher => socket) but that the reverse direction (socket backward
via prev_bio) showed that prev only pointed to one of the ciphers.
(This was expected and makes total sense, of course, since prev_bio
can only point one place.) I don't know the underlying workings
of the BIOs, so I don't know if this is a problem or not.
So, trying to outsmart things entirely, instead of creating the socket
bio and then attaching it to two different ciphers separately, I
first cloned the socket bio with BIO_dup_chain and used BIO_push to
stick uniq copies of it onto my two cipher bios. Thus my BIO chains
looked consistant both in ->next_bio and ->prev_bio order.
I didn't really think this necessary, but thought I'd try to see if
it'd get rid of the 22% failure rate. Unfortunately, it acted
the same - 22% of the time I got a wrong final block length error,
even though the other end of the socket is sending the exact same
data every time.
Any ideas? Any good debugging method to see the data coming through the
socket bio before it hits the next bio (cipher) in the chain to be sure
that the data on the wire is the same data coming in my bio chains?
Am I adding an encrypt and decrypt bio onto my socket in a totally
brain dead manner?
--
Brian Hatch Stupidity is
Systems and not a handicap.
Security Engineer Park elsewhere!
http://www.ifokr.org/bri/
Every message PGP signed
pgp00000.pgp
Description: PGP signature
