Dear Tails devs
I see these comments on forums lately. Any of this true? Also wouldn't a generic Tor Browser Bundle installation also pick random entry guards? I don't see the problem here:
---------- quote ---------- Until Amnesia has persistent entry guards I would steer clear of it. Liberte has some shit design choices, their cables private messaging system being one example. They have a lot of advantages over tails as well though, tails lack of persistent entry guards is a huge hit to it and even if you load it from a snapshot it only partially fixes the issues. If you must use a live CD just keep in mind that if you use Amnesia you are going to be significantly degrading the anonymity provided by Tor, particularly if you don't load from a snapshot.
The thing that sucks about amnesia and other live Tor CD's is the fact that entry guards do not stay persistent between reboots. This leads to entry guards rotating much faster than they should and puts you at high risk of profiling attacks (end to end).
You should run it in a virtual machine and load it from a snapshot. If you use it as a traditional live CD, booting from it each session, you will greatly increase your risk to profiling attacks until they make the entry guards Tor selects persistent somehow. You really need to make sure to load it from a snapshot, its a huge risk to the anonymity of Tor to select new entry guards that quickly.
Liberté Linux has no persistence of entry guards. I also don't see any compelling reason to implement that (by, e.g., making /var/lib/tor/data persistent). If Tor is less secure when started up with a fresh state, this is a problem with Tor, not with the package shipper. Although, judging from Ticket #2653, if Tor developers decide that selecting guards according to a seed is a good idea, then fine. For all I care, they can use a hash based on the hidden service public key for that automatically — the hidden service is required for cables communication, to which the quoted clown referred as one of Liberté's “shit design choices” (Creepy Wonka says: Do tell me more about your amazing insight). —MK
The issue is not that Tor is insecure when started with a "fresh state", but when started repeatedly with a "fresh state". One issue is that with non-static first hops, the probability of a passive correlation attack will eventually become 1. Static first hops (i.e. entry guards) will protect against this attack with probability O((n-c)/n), where n is the total number of nodes in the network, and c is the number of compromised nodes. Another issue is that hidden services becomes much less hidden without entry guards.
For more, see the linked papers in the Tor FAQ: What are Entry Guards?
After skimming Paul Syverson's Locating Hidden Servers I really think Liberté should make
/var/lib/torpersistent to make cables communication safer. Of course, even without that the speed of the attack described in the paper would be limited by the number of reboots the Liberté user does, but still...I am aware of the motivation behind entry guards, but I believe that this should be handled at the network level, and not by relying on certain usage patterns. For instance, strict requirements for a relay to be able to serve as an entry guard (i.e., have a Guard flag) are a good start. Besides, this “we need to pick entry guards and stick to them” reeks too much of the usual academic knee-jerk reaction: someone (L. Øverlier and P. Syverson) publish a paper describing an attack → this must be fixed now, and let's wait for other research to discover problems with the employed fix. See arma's comment about fingerprinting users by chosen entry guards, for instance. Why couldn't the Tor project employ some middle ground, by, e.g., assigning entry guards by user's IP address? Knee-jerk, I guess.
But what about fingerprinting considerations above? Did the Tor people already decide which evil is the lesser one? I guess that /var/lib/tor/data can be made persistent, although that would probably ruin tordate-based time synchronization.
—MK