On 10/15/12, Maxim Kammerer <m...@dee.su> wrote: > Hi, > > Lately, the question of persistent Tor entry guard nodes in live > distributions has been raised in a few places. Typically, the > conclusion is that /var/lib/tor/data should be made persistent. I see > it as problematic, since a live distro can be expected to be moved > around more frequently than a typical desktop, or even a laptop. If we > consider the current 882 Guard+Fast+Stable nodes in Tor consensus as a > rough (or perhaps exact, not sure) estimate of nodes that can be > selected as guards by Tor clients, then there are ~114M possibilities > for selecting 3 guards, which, essentially, uniquely identifies a Tor > user to a close traffic observer. > > In last comment in [1], Roger says that location-aware “profiles” > would be nice, but difficult to implement safely. I don't see any > problem with implementing such profiles, and think that the > implementation can be even safer. It's pretty simple, actually: keep a > secret persistent cookie, then upon Tor startup, concatenate it with > the current public IP (or, say, its /24 part), use the result as a > salt for hashing candidate guard nodes fingerprints, then sort and > take the top 3. The additional benefit is that an attacker who gains > access to Tor persistent state will not know which guard nodes were > used without knowing an IP (although, a global observer might still > iterate over all IPs that connected to Tor). There is a minor > bootstrap issue of finding out the public IP (does this require an > existing circuit at present?).
https://bugs.torproject.org/2653 The hardest part is load-balancing among the possible entry guards. Robert Ransom _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
