[liberationtech] Mega

[Jacob Appelbaum]

micah anderson:
> Nadim Kobeissi <nadim at nadim.cc> writes:
> 
>> Hasn't Retroshare also been under criticism for a lack of audit?
> 
> I've always wondered why something like Mega gets a lot of attention and
> people audit it pretty much immediately, but something like Retroshare,
> which has been around for a while never has the eye of Sauron pass over
> it.

I've wondered the same thing. I think it is because it is small, makes
wild claims, it calls a lot of attention to itself and is written in a
context that many people seem to love to hate.

> 
> So, to those of you who immediately tore Mega apart when it was
> launched, I ask you... why did you swarm over the latest new thing that
> nobody has even used, but haven't touched something like Retroshare (or
> even more core componants that we depend on)? Why does something like
> Mega get all the attention of "crypto researchers", but nobody has
> bothered to look at Retroshare?
> 

I'm not sure that it has no one looking. It uses GnuPG/OpenPGP, it uses
email (or a manual paste) to connect up users, it doesn't seem to
provide any anonymity for discovery of friend to friend connections,
what little anonymity it provides is called TurtleHopping (
http://retroshare.sourceforge.net/wiki/index.php/Documentation:TurtleHopping
) and it is questionable at best, and so on.

> In any case, lack of audit means only one thing - it should be
> audited. I wonder why nobody has.
> 

Other than weird claims like ("There's absolutely no way to know where
turtle packets come from and where they go" -
http://retroshare.sourceforge.net/wiki/index.php/Documentation:TurtleHopping#Anonymity_issues
apparently the older version of
https://retroshareteam.wordpress.com/2012/11/03/retroshares-anonymous-routing-model/
). Their anonymity model is... not impressive (
http://en.wikipedia.org/wiki/Retroshare#Anonymity) from what I've seen.
I'm not clear on most of the Retroshare design. Is there a threat model?
Or the way they wish to model an adversary?  What bugs would be out of
scope (gnupg bugs, openssl bugs, libssh bugs, etc) and what would be
reasonable to report?

The project seems like it is nice but it is seriously odd. For example,
consider this:

 "Friend to Friend (F2F) is the new paradigm after peer-to-peer (P2P).
  In a P2P network you connect to random peers all over the world.
  A F2F network only connects with to your trusted friends.
  This makes the network significantly more private and secure.

I'm fairly certain this isn't a new paradigm...

There are lots of questions that come to mind when looking at their wiki
and at their design documents. For example with these long term keys,
they support a model of sharing with friends, what happens if the keys
are compromised? Does it provide forward secrecy, Non-repudiation or
repudiation? I admit, I didn't look closely but a strongly identifiable
file sharing network sure has some important design considerations.

A few other quick issues that come to mind include the use of Speex for
VoIP (Variable bitrate operation? ruh roh!; the authors of Speex suggest
using Opus as it has support for both CBR/VBR), they seem to have a lot
of older versions of third party software hard coded into their build
files ( see openpgpsdk.pro for more details ), they seem to play fast
and loose with some traditionally unsafe C/C++ stuff rather than
defensively, they seed some RNG use with time (srand(time(NULL)); in
services/p3service.cc:240 - it might be better to use OpenSSL's random
byte generating functions) and so on.

If anyone wants to dive in - the source code is easy to grab:

  svn checkout svn://svn.code.sf.net/p/retroshare/code/trunk \
               retroshare-code

I'm not sure that this counts as anything more than a giggle test and I
did giggle a bit. Though I appreciate the ideas and the effort, I'm
fairly certain I won't use it or suggest using it to others without
deeper auditing.

Hope that helps,
Jake