<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> -----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. 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. > > 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. > > > 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. > > > Cheers! > David [1] <a class="moz-txt-link-freetext" href="https://github.com/ricochet-im/ricochet/issues/68">https://github.com/ricochet-im/ricochet/issues/68</a> [2] <a class="moz-txt-link-freetext" href="https://trac.torproject.org/projects/tor/ticket/12500">https://trac.torproject.org/projects/tor/ticket/12500</a> - - 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----- </body> </html>