On Sun, Jan 10, 2010 at 12:43 AM, Brian <[email protected]> wrote: > > > On Jan 9, 9:15 pm, Chris Morgan <[email protected]> wrote: >> On Sat, Jan 9, 2010 at 9:49 PM, Brian <[email protected]> wrote: >> >> > On Jan 9, 4:36 pm, Chris Morgan <[email protected]> wrote: >> >> Hi Brian. >> > >> >> Why not use ssl for an encrypted compressed connection to your server? >> > > Do you know if it is possible to use ssl for just the encryption? > I'm > already using bzip2 for compression and am happy with that. >
I'm not sure ssl compression is on by default, see http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html > >> > I'm thinking about that, but my first look at openssl left a bad taste >> > in my >> > mouth. The API seemed a mess. I'm not sure yet about crypto++, but >> > want to explore it more. It is at least written in a much better >> > language >> > than openssl. >> >> Looking at some old c++ code I have here I see three calls to set >> openssl up as a client and then you can start calling SSL_read and >> SSL_write on the connected socket. There is a bit of complication in >> checking for errors etc but it wasn't too difficult to wrap it to make >> it look the same as normal sockets, at least that's what I ended up >> doing. Oh, and I ended up with an async implementation as well since >> it suited the application better. >> >> >> Openssl is easy to use and a standard protocol that would save time >> >> from re-inventing the wheel. >> >> > Can't I get something as good or better with crypto++? >> >> Probably. Consider the complexity of the issue and the time you'd save >> by using an existing and very well tested and debugged library. >> >> You would need to consider handshaking, key exchange, all kinds of >> error conditions and you would still end up having to deal with the >> complexities of sockets. Imo its a no brainer going with an existing >> library. You would probably spend a lot less time figuring out how to >> use openssl than you would rewriting your own. Plus, if you ended up >> using openssl you could port your application to any other language >> that supported ssl without having to re-write your custom transport >> layer code for that language. We ended up moving from c++ to c# in >> multiple parts where first the server was updated to c# but the client >> was c++, then the client was moved to c#. >> > > I'm wondering a little though why you are hanging around this list. > Do you use crypto++? I guess crypto++ doesn't have it's own ssl > implementation. I wasn't 100% sure. I maybe have some > misconceptions about crypto++. > I hang around here because I use crypto++ to perform sqlite encryption. I also rewrote and submitted a patch for faster aes crypto code in crypto++ several years ago. ssl is a lot more than just the core crypto algorithms. Ssl *could* use crypto++ for its backend processing but even without the crypto algorithms there is a lot that goes on in ssl in terms of negotiating protocols etc. You wouldn't need that for your custom implementation of course but what is useful is the initial key exchange and using an encrypted transport system that has been checked and debugged for security holes, bugs etc. Plus the openssl guys would maintain it for you :-) > It would be nice to find a C++ implementation of ssl. I found a > C++ wrapper of openssl, but in general don't like that sort of thing. > Yeah. I'm not sure how much wrapping ssl would get you. Its just a few c calls to set it up and then SSL_read() and SSL_write(). Chris
-- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
