On Thu, Jun 03, 2004, Alexandru Ciobanu wrote: > Hello openssl-users, > > I'm facing difficulties implementing a rather common behavior of a > client/server application using BIO chains. > > Basically, all I want is to send several strings through the chain > from the client to the server, e.g. for authentication purposes. > > On both the client and server side I have prepared the BIOs, and > chained them accordingly: > ---------------------------------------------- > c = BIO_new(BIO_f_cipher()); > s = BIO_new(BIO_s_socket()); > BIO_set_fd(s, fd, BIO_NOCLOSE); > BIO_set_cipher(c, cipher_type, key, iv, 1); > s = BIO_push(c, s); > ---------------------------------------------- > > The things are OK when I transmit a single string trough the chain. > > Client: > ---------------------------------------------- > i1 = BIO_write(s, some_text, strlen(some_text)); > ---------------------------------------------- > > Server: > ---------------------------------------------- > j = BIO_read(s, buff, sizeof(buff)); > ---------------------------------------------- > > However I am forced to flush the BIO chain after writing the data, on > the client side, in order, to get valid data on the other end(server). > I guess this is something related to EVP_EncryptFinal, which must be > called to validate crypted data. > > From this moment, if I transmit other data from client, using the same > chain, I will not be able on the server side to read the both strings. > ---------------------------------------------- > i2 = BIO_write(s, other_text, strlen(other_text)); > ---------------------------------------------- > > > I don't know why this is happening. It looks to me that I must > include some other BIO in the chain. Anyway I need your help to > understand this strange behaviour, and to design a solution. > >
This really reflects the behaviour of the underlying cipher padding. It isn't designed to handle multiple records decrypted one at a time. You should be able to write more data by calling BIO_reset() on the chain: that will reuse the existing key and iv. However there are problems with this approach because then the block padding will look just like real data to the decryption side. This means that the decrypt side will need to call BIO_reset() at an appropriate time too. However the block padding will be confused because the receiving side will not know where the end of the encrypted data comes because this is signalled by EOF. One way round this is to include your own padding scheme and disable standard block padding on the underlying EVP_CIPHER_CTX. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
