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?). Comments? Also, is making just /var/lib/tor/data/state persistent (instead of the whole directory) enough at the moment to have persistent guards? [1] https://blog.torproject.org/blog/research-problem-better-guard-rotation-parameters -- Maxim Kammerer Liberté Linux: http://dee.su/liberte _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
