[messaging] fyi: metadata-eliminating tor-based chat program: Ricochet

[David Goulet]

On 19 Sep (17:03:33), Trevor Perrin wrote:
> On Fri, Sep 19, 2014 at 1:38 PM, Tim Bray <tbray at textuality.com>
> wrote:
> > A number of things about this one made me kind of uneasy.  The
> > clichéd tone of the article “high-school dropout trumps NSA!”  The
> > complete absence of input from anyone who wasn’t a  project insider,
> > and the dissing of competitors who are actually shipping working
> > software.
> 
> Seems like a critique of the journalism, not the project.
> 
> The project looks like a simple-ish chat protocol using Tor Hidden
> Services for peer-to-peer connections.  I think it relies on Tor HS
> for encryption and server-auth, and adds some fairly simple
> client-auth.
> 
> There's a slew of new apps using the model of "Tor Hidden Services for
> peer-to-peer connections".  We had a thread about that for email-like
> messaging, e.g.
> 
> https://moderncrypto.org/mail-archive/messaging/2014/000434.html
> https://moderncrypto.org/mail-archive/messaging/2014/000447.html
> 
> The advantage of this model is that your metadata isn't seen by a
> server.  A less obvious disadvantage is that, compared to proposals
> where both parties use Tor as clients to communicate via some server,
> users might be exposed to things like: - hacking / DoS targeted at
> your Hidden Service - deanonymizing users via Hidden Service attacks -
> deanonymizing users via monitoring HS uptimes - linking users via
> monitoring Alice's HS uptime, and correlating it with Bob's polling to
> see if Alice is up
> 
> I also don't know how well Tor HS would scale to large numbers of
> people using it this way.  But that would be a good question for a HS
> expert (do we have one?)

I'm yet far from a Tor HS expert but I can at least comment a bit on
that. Also know that I'm starting very soon with Torproject to work on
improving scalability and reachability of hidden service so this is
exactly the kind of problematic I'm interested in.

On the question of scaling, I think it's still an open question to be
answered as far as I know. The HS design I think might not be that
suitable for a p2p meaning spawning a lot of HS quickly with a low
lifetime.

Let say that a new system (ricochet) brings in 500k users everyday. Just
adding this amount of traffic on the Tor network is probably an issue
but staying on the HS system subject, it would mean that 500k HS
descriptors are uploaded to directories regularly which means 500k new
rendez-vous points and introducing points are created and that itself
might be a non negligeable point of contention on the network. An HS
directory is basically a DHT storing HS descriptors but that part does
not worry much to scale well.

Keep in mind that HS are reachable, once published meaning started,
after 30 seconds to 2 hours since there is a component of randomess on
when the tor HS decides to upload the descriptor to the directories.
This alone brings a reachability issue in an IM system.

There are possible solutions to improve reachability and itself the HS
design I think can scale in terms of data structure and holding the
information for the network to work. I'm way more worried about the
network itself if it can handle yes the low traffic of IM compare to
torrent but using HS on both ends means a lot of new circuits being
created and way more inter relay communication for the HS system. (And
I'm not including all the possible attacks to deanonymize clients with
using HS as a p2p on desktop/phone).

Again, that "might" be a no brainer for the current Tor network but it
absolutely needs to be measured and tested! :)

Cheers!
David

> 
> 
> Trevor
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140922/c672c9f1/attachment.sig>