> 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 [EMAIL PROTECTED]
