A few comments inline, please note that Mr. Asta uses the > indents
"backwards"
On 02-08-2013 00:58, Thomas Asta wrote:
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 <mailto:jb-open...@wisemo.com>>
GoldBug.sf.net <http://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?
Briefly, I only spent an hour or so on it.
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.
Yes I read more comments than code. What I am looking at is idioms like
extending a string to a given length before filling it, appending to an
always empty string, repeatedly requesting items by their string name etc.
++++++
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.
Why?, they contain roughly the same functionality.
- 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.
You mean a protocol called "echo" which has nothing to do with the
RFC862 standard 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.
The documents are very sparse, it was unclear if the text of that file
had any applicability to GoldBug.
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
<http://cseweb.ucsd.edu/%7Emihir/papers/oem.html>, e-t-m.
The documents in Documentation say you are doing "Encrypt-and-MAC",
the top (worst) option in the table on page 5 in that paper.
- 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.
Yes, but you first pad to a multiple of the block size, then add 4 more
bytes and expect those 4 bytes to be the last ones after decryption.
- 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.
I am familiar with RSA and its proper and improper uses. I am not entirely
familiar with the gcrypt and Qt functions used, but I see no explicit
references to any of the known good RSA "modes", such as those from PKCS#1.
- 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.
But are the different Base64 lines in the protocol description encrypted
separately or together?
- 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.
This has nothing to do with HTTP or SSL. It is about basic steps to
prevent attacks on the keyed hash from commonly available password
cracking programs.
- 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.
The whole point of GoldBug appears to be to counteract the attacks
discussed by a certain refugee. Those are all about "traffic analysis".
The way other users forward messages without knowing who they are for is
exactly the kind of thing one would do to prevent eavesdroppers from
finding out who is talking to who. That is why I am pointing out a hole
in the design of that very feature.
- 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.
HTTP traffic is not all Base64 text, in fact, most HTTP traffic is
compressed pictures/videos and some HTML, none of which looks like
variable length lines of Base64 strings with identifying HEX numbers in
front.
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
