[guardian-dev] BitTorrent Bleep - another secure/private chat app

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/09/14 14:20, Nathan of Guardian wrote:
> They should have learned more from Twister: http://twister.net.co/
> since they have thought about the metadata issue a lot:
> 
> "twister is the fully decentralized P2P microblogging platform 
> leveraging from the free software implementations of Bitcoin and 
> BitTorrent protocols."
> 
> The other news yesterday was about Richocet aka Invsible.IM, which
> is basically just TorChat evolved (P2P hidden service chat).
> Unfortunately, it has a very fragile binary protocol, and depends
> on the idea of massive scaling of Tor Hidden Services, which they
> were not designed to do:
> 
> https://github.com/ricochet-im/ricochet
> 
> Any comment or update from Briar folk about either of these
> systems?

(CCing the hidden-services list in case anyone there wants to offer a
more informed opinion than mine.)

I haven't looked deeply into Twister or Ricochet, but here are my
initial thoughts.

I'm really impressed by Twister as a piece of distributed systems
engineering, but I'm not sure its metadata privacy is terribly strong.
Anyone can participate in an account's swarm of followers to see who
else is in the swarm and to receive messages (including encrypted DMs)
sent by that account. That enables some basic traffic analysis: anyone
can see that Alice and Bob participate in each other's swarms and
therefore follow each other; if Alice sends a DM at 12.01, Bob sends
one at 12.02, Alice at 12.03, and Bob at 12.04, what are we seeing?

It's interesting that Invisible.im has switched from XMPP-over-Tor to
Ricochet - I wonder whether that choice was made for protocol reasons
or to avoid fragmentation of effort. I suppose presence is one aspect
of XMPP that's a poor fit for P2P, as it requires you to poll for
connections to your peers even when you don't want to talk to them. (I
think you've argued in the past that presence is a poor fit for mobile
too, which I agree with - so maybe a custom protocol is a good choice
here.)

Ricochet's binary protocol is moving to Protocol Buffers, which should
help with the fragility concerns. In any case, consider the
alternatives: I don't think either libpurple or libsmack could really
be described as bulletproof...

I don't see anything in the Tor HS design that would prevent it from
supporting a large number of low-traffic services. The HS directories
are essentially a DHT accessed via Tor, so the number of DHT nodes has
to grow with the number of services - but as far as I know the HS
directories are just ordinary relays, so this reduces to the perennial
problem of ensuring enough relay capacity.

I do have concerns about the HS design and implementation when
services lose connectivity frequently, but I'm hoping those can be
addressed at the endpoints by (a) not caching hidden service
descriptors and (b) publishing an empty set of introduction points
when a service knows it's going offline. When I get some time to work
on this again I'll do some experiments to test those hopes.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUHGscAAoJEBEET9GfxSfMvuoH/R7OipPi9k97e49SxjBmDDPJ
pCEZt01/0Y7SyK3eLQy5aeuwAgvaVhcbScjdOn58oHBxWopA90nlGmHz7HUl+TML
QLRWnhpBDcd0Tk6BaoV7gvVYMStTRTPYZxtX8+8QjIDzCwuIb24HiRd7YSFsRNLX
uXuL7PGBwOrudYG289+WK5g8aLs0ZC8kgPuxaKGz8IcUN9duKKRkrv+Oi7bm4jzQ
/STc2Nx6pgVMdpZU6gPFi4AlvmDmr+bdnAiXhzoq+JH56A0GshHtadrNGD6NZA+f
g0hVe/HYexWjRc3zsN7/v21MKiMApvnbcghg8AM44oJpKOXU3aqfHAPmvvqPPqw=
=mDrl
-----END PGP SIGNATURE-----