On 31-07-2013 21:33, Randolph D. wrote:
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.
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.
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.
++++++
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.
- 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.
- 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.
- 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.
- Padding before symmetric encryption is done wrong in the code and
probably only works via gcrypt doing its own padding on top.
- 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.
- 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).
- 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.
- 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.
- 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.
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
