Thanks both, though I think new software deserves constructive criticisms and not some sort of brief and impulsive whims.
But thank you for your time, so these items can be discussed by more experienced people. Don´t reduce a lot of work of developers into your personal interpretation of failures, at it seems to be a quick done writing? New approaches need to be appreciated more, And revised carefully based on the validated experts opinion. Not with fast rush items and opinions. Though they are now rised and can be further evaluated... Any third opinion? Thank you!. 2013/8/2 Thomas <thomas...@googlemail.com> > Dear Jakob, > thanks for rising the items, which should be discussed, but first let´s > start with your footer: > " This public discussion message is non-binding and may contain errors." > ;-) > Find some comments "inline" .. > Regards Tom. > > > > 2013/8/1 Jakob Bohm <jb-open...@wisemo.com> > > > GoldBug.sf.net <http://GoldBug.sf.net>- Secure Instant Messenger > > http://goldbug.sourceforge.net/ > Please evaluate the OpenSSL implemntation > Any comments, is it really secure? > as it implements the new echo chat protocol, which is designed for only > non-plaintext chat. > > > > Looking at the project on sourceforge, I am not convinced this is > as good as it wants to be. > > First off, the main page is a lot of lofty goals with little > substance, it took some digging to get to the code. > > > You didd digg into the code and also the functionality? > > > Secondly, the code repository is a mess, it looks like an unfiltered > mirror of the authors working directory, including compiled binaries > and copied library parts. > > > They seem to do so, but that´s good to have for a mainly windows project > > all DLLs files available. NO missmatch might occur. > > > The code is excessively string based, with lots of idioms that make > sense in prototyping languages like perl, but not in C++ code, even > when using Qt. > > > Many comments in the code to read and understand it easily. > > > ++++++ > Now for the crypto part: > > - Most of the code seems to be using gcrypt, not OpenSSL libcrypt. > I am not familiar enough with that library to check what each > function does. > > > a. Both OpenSSL and libgcrypt are used. > > > - The code was originally intended as some kind of P2P > "stumbleupon"-like link sharing system called "Spot On" and still > contains leftovers from that system. > > > b. GoldBug uses Lib Spot-On. Lib Spot-On attempts to implement a total > algorithm called Echo Protocol. > > > - The code seems to store local data in an SQL database. Some code > comments seem to indicate that the users passphrase and/or private > key is stored there, which would be a security problem. > > > > c. Private and public keys are stored in an encrypted manner in > databases. Other attributes are also stored in an encrypted manner in local > databases. Encrypted items are described in Documentation/ENCRYPTED. > Storing encrypted data is not a security issue. > > > From the unclear text files about the protocols, and some of the > source code, it looks like some basic encryption mistakes are being > made: > > - A (keyed) hash of the plaintext is sent in the clear for no > good reason. This is wrong, either send the hash encrypted along > with the message or hash the encrypted message, not the plaintext. > Some people have argued that encrypting the hash is a bad idea (I > disagree), but every professional I have read agree that if you > don't encrypt the hash, the hash should be of the encrypted > ciphertext, not the decrypted plaintext. > > > e. The original implementation sent an encrypted form of the hash. The > has was based on plaintext data. The behavior was changed per > http://cseweb.ucsd.edu/~mihir/papers/oem.html, e-t-m. > > > - Padding before symmetric encryption is done wrong in the code and > probably only works via gcrypt doing its own padding on top. > > > f. Padding is achieved with 0 bytes if the length of the data is less > than the block length. See > http://en.wikipedia.org/wiki/Padding_%28cryptography%29#Zero_padding. The > size of the original data is appended to the data. The data is then > encrypted. See CBC and CTS. > > > > - The way symmetric keys are passed in and out of the RSA algorithm > looks fishy and may be badly broken, though a thorough knowledge > of gcrypt and Qt is needed to figure out exactly what is going on. > > > Yah, get familiar with libgcrypt and RSA and Qt. > > j. Clearly you don't understand the product. > > > > - It looks like different message parts are encrypted separately. > - It is unclear how often symmetric keys are being changed (once > per line, once per message, once per user changing their password, > never). > > > g. Symmetric keys are generated per message. > > > - The way passwords + salt are used for the keyed hash looks like > the crucial key derivation step/anticracking step is missing or > buried inside gcrypt defaults. > > > l. The data is intended to mimic HTTP traffic. SSL is non-essential. > Participants communicate with approved keys. If SSL is available, then it's > used. Regardless, the data is encrypted separated outside of the scope of > SSL. > > > > - The fact that messages are not forwarded after being recognized > by their recipient allows spies to trace them (traffic analysis) by > seeing where they enter and leave the network, thus nullifying the > whole point of cryptographically hiding the destination. > > > > k. Yes, message types are clearly visible. Simple to resolve. I suppose > you'd like your e-mail headers encrypted. > > > - Lots of message attributes are visible because too much happens > outside the encrypted envelope. > > - Base64 encoding is not necessary, wastes bandwidth and increases > the potential for cryptanalysis against the SSL tunneling, if used. > > > l. The data is intended to mimic HTTP traffic. SSL is non-essential. > Participants communicate with approved keys. If SSL is available, the it's > used. Regardless, the data is encrypted separated outside of the scope of > SSL. > > > > All in all, I am not impressed. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > >
