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

[David Goulet]

On 23 Sep (15:25:16), John Brooks wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I'm the author of Ricochet, so take this with the appropriate level of bias.
> 
> On 9/22/14, 8:28 AM, David Goulet wrote
> >
> >
> > 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.
> 500k is an insane number; the total estimate of Tor clients is around
> 2.5 million. There would be serious scaling issues with that many users.

Indeed, it is a large number, my point was more about the fact that it
might come to this user base one day and thus thinking *now* about the
scaling of HS is imo very important especially when other "p2p similar
service" will start to use this technique.

> 
> It's also worse than you've described. Every descriptor is uploaded to 6
> mirrors, and each service has 3 introduction points. There isn't much
> research (that I'm aware of) on how tor relays scale with the number of
> circuits, so I can't very well estimate those effects. I expect the
> current design won't harm the network up to around 10000-20000 active users.
> 
> The most expensive part is polling for connections, not publishing
> services. We can reduce that very significantly already[1], but I hope
> we find a way to remove it entirely - maybe with some PIR scheme.

Nope I think you are right, publishing is a no brainer for the current
HS design, it's the amount of connections that are created (circuit)
that looks to be the expensive part.

> >
> > 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.
> This was the original intention, but Tor hasn't actually worked like
> this for a very long time. Due to a bug[2] in the code, hidden services
> are always published immediately, and in my experience they work within
> 30 seconds.

Oh didn't know about this bug, thanks for the pointer! :)

> >
> >
> > 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! :)
> I hope someone does! I'd like to have some clear direction on where
> scalability needs to be improved, so I can help make it happen.

I'll soon start to work (this year) on this kind of measurements so I'll
be happy to keep you in the loop if you are interested (and even this
mailing list).

Cheers!
David

> >
> >
> > Cheers!
> > David
> [1] https://github.com/ricochet-im/ricochet/issues/68
> [2] https://trac.torproject.org/projects/tor/ticket/12500
> 
> - - John
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> 
> iQEcBAEBCgAGBQJUIeU8AAoJEP+XxT8YPARdBbwH/2VsXjQREwMko4jiapJl7jDF
> +Ux7CMBFoSEUV7A2GHx3J8HVlCsfpo7gJpVp7YhIv313zSLphTZA9QeWx1J+V57z
> ti+CiZBmLd2lCkgZnvbHQ+2/AqJIfWnwByNzXn+S6HgUPn6T0Bw9TkTyPaGitJyi
> FCPjmToyL4mW6LmA+TgIFpOYhjM3neAd0vJCiD6P+I/j+sCIjR9SgZ+RMN/w7Nwn
> Vx5a+o49yvcqmIGdT2A2nLzlfXz+ikGvGYkWcf0MxK1Albsc2yACdF5FzE/Pdku1
> A6PyHpU95gKHblxDGXQs64pGzwYWFPueRWPMT1+ebCpV6LoV92x/UrWLYUXXmZk=
> =wa7M
> -----END PGP SIGNATURE-----
> 
-------------- 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/20140923/52f913d7/attachment.sig>