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 <[email protected]> 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 [email protected] Automated List Manager [email protected]
