On Wednesday, July 13, 2011 at 8:02 PM, Brandon Wiley wrote:
> > Cool stuff. I like how the system can be automated and self-funding. > > With regards to bootstrapping, giving out one node at a time is not a useful > defense because requests can be parallelized. [1] Moving nodes is similarly > useless because the attacker can continually map the network using free > parallelized requests. Therefore, requesting a node address needs to cost > something. [2] Since you already have tokens, you can just make it cost a > token to request a node address. I agree with most of your points, but if we make users redeem a token to in order to access bootstrapping, they have to already have tokens, which is another bootstrapping problem in itself. Also, a determined adversary could just purchase enough tokens to perform the same attacks. Admittedly, we might make a lot of money from the censors in the process, which would be cool. > > To solve the initial introduction problem, you need to include fresh node > addresses with the distribution of the executable. You could in fact dispense > with the directory servers, which add no defense, and include fresh node > addresses with each executable upon download. For instance, with BitTorrent > we had a neat trick where we would encode the URL to a torrent file at the > end of the uTorrent executable (dynamically for each user when they > downloaded it from the web server) and the program new how to look for and > extract this URL upon startup. If present, uTorrent would automatically start > downloading this torrent. You could use a similar technique here. Much as > above, getting fresh peers, in this case by downloading the executable, > should cost something so that it can't be parallelized for free. This is a cool idea. Definitely will investigate this more. > An alternative to paying per node address is to pay to establish an identity > and then use a DHT to map node addresses to identities so that you have a way > to obtain new addresses as they change due to churn, but mapping the whole > network requires multiple identities and so once again incurs a linear cost. > [2] > > Best of luck with your project! > > [1] Sybil attack (http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf) > [2] Arcadia (http://blanu.net/Arcadia.pdf) Thanks for your comments. Very much appreciated! -Nick Jones > > On Wed, Jul 13, 2011 at 6:32 PM, Nick Jones <[email protected] > (mailto:[email protected])> wrote: > > > > > > On Wednesday, July 13, 2011 at 4:58 PM, Aaron wrote: > > > > > I have a few questions > > > > > > Q1: Regarding network bootstrap protocol: Consider the scenario where > > > a censor mines the boostrap node list and blocks these nodes. Do you > > > implement any mechanisms to prevent a censor from obtaining the entire > > > set of bootstrap nodes? Similarly, aren't public directory servers > > > also vulnerable to censorship? > > > > Currently, we don't have any major protection from enumerating the list of > > bootstrapping nodes. > > It is definitely a problem we are aware of, and we're thinking about > > possible ways to protect > > them. In our design, we only give out one bootstrapping node at a time, > > with the hope that this > > makes enumerating them somewhat more difficult. Additionally, if we can > > detect that a > > bootstrapping node has been blocked, we can use the elasticity of cloud > > hosting to move it to a > > new IP or a new cloud. Admittedly, this may devolve into a cat and mouse > > game of moving the > > bootstrapping nodes around. > > > > Similarly, since you learn about the bootstrapping nodes through the > > directories, the directories > > have many of the same problems and solutions. If the directories stay at a > > static IP/DNS name, > > then they will be blocked quickly. However, if the user still has a cached > > valid directory from the > > last time he was connected to COR, he could build a circuit and then > > retrieve an updated directory, > > assuming at least some of the nodes from the last directory retrieval were > > still active. We can > > move the directories around within the cloud, but then you need a > > "directory of directories", and > > that gets messy. > > > > Admittedly, our system doesn't fundamentally solve the bootstrapping > > problem (of new users > > gaining access), but we hope that it makes it more difficult for existing > > users to be blocked. > _______________________________________________ > tor-dev mailing list > [email protected] (mailto:[email protected]) > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
