On Sat, Jan 9, 2010 at 10: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. >>> >>> Yeah, c++ serialization is a pain. >> >> If the only option for C++ serialization were various serialization >> libraries, I would agree. The C++ Middleware Writer is improving >> matters. >> > > Cool. I'm not suggesting that its a bad thing to have its just that > when you look at the c# equivalent for serializing an object to a > file, > > Stream stream = File.Open(filename, FileMode.Create); > BinaryFormatter bFormatter = new BinaryFormatter(); > bFormatter.Serialize(stream, objectToSerialize); > stream.Close(); > > it becomes apparent how useful a built in serialization system can be. > If your system is only a fraction of as easy as this is then it will > be a huge benefit to c++ developers. > > > >>>One reason I'm a huge fan of c#. >>> >>> Why not use ssl for an encrypted compressed connection to your server? >> >> 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#. > > Chris >
To clarify further, crypto++ is almost certainly capable of being used to create a transport system that is more secure than openssl via longer key lengths. A couple of questions you might want to consider first are whether: 1. openssl's crypto implementations are good enough, secure enough, for your use (I imagine they are since they are for my bank etc) and 2. what are you gaining from having your own pick of crypto implementation, handshaking protocol etc. 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.
