> The documentation's poor at best, and I don't completely get the
> general concepts. From reading examples I figure that only the
> BIO_f_ssl does encryption-decryption when written into? so what should
> I do if I want to provide an api that has functions b_encrypt and
> encrypt_flush?


I think you have a wrong notion in your head that's leading you astray. You
are thinking about an SSL connection as a module that you put some plaintext
into, some encrypted data comes out, and then you send that on a socket, you
get some encrypted data back, you feed that into the SSL connection, and you
get some plaintext back.

While that certainly *sometimes* happens, other times it doesn't happen.
Sometimes you want to hand plaintext to the SSL engine, but it can't encrypt
it yet because it hasn't negotiate the key. Sometimes data comes in from the
socket that's protocol data and doesn't correspond to application data.

Your whole concept of "how big does my buffer have to be" is based on the
mistaken notion that it's useful to try to track what goes in to its
corresponding output. It's not. That's the SSL engine's job.

It is better to think the the SSL engine as a box that has four 'links'. One
is the one you feed plaintext into so that it can be encrypted and sent. One
is the one encrypted data comes out of. One is the one that you get
decrypted plaintext from. One is the one that data that comes in from the
wire is fed into. The relationship between these four links to 100% the SSL
engine's business, and you shouldn't make any assumptions about it.

If you hand plaintext to the SSL engine, at some point it might hand
encrypted data to you to send over the Link. Or it might not. That's not
your business. If you get encrypted data from the other end, give it to the
SSL engine. It might output some plaintext for you to treat as received, or
it might not. That's not your business.

You have two general approaches to choose from. You can implement a BIO and
OpenSSL will call into your BIO whenever it needs to send or receive data to
or from the other end. This will result in your calls to SSL_read/SSL_write
making calls into your own send/receive functions when the SSL engine needs
to interact with the link to the other end. This is probably the simpler
approach and it makes deadlocks easier to avoid.

The other way is to use BIO pairs. With A BIO pair, you actually
independently manage all four links independently. When you get data from
the other end of the SSL link, you will actually 'write' it onto the
appropriate link. When you make forward progress, you will actually call a
'read' function to get data from OpenSSL that you send to the other end.
This is a bit trickier to do as it is easy to inadvertently cause deadlock,
especially in non-blocking implementations.

DS


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org