I attempted to create an “entry guard technical” and “entry guard non-technical” but it didn’t look good (duplicating information). I settled on adding some info on “traffic analysis” in the introduction hoping users would better understand Tor/entry guards are only a imperfect/partial solution. I’m not even sure if the introduction should be edited at all since its almost verbatim from the Tor wiki?
There are minor edits in other areas but not worth posting here since the entire entry guard chapter would need to be posted along with them. Plus they’re not very important edits.
If any changes are needed please let me know!
The only edit here are to the first paragraph of the wiki/Tor#Entry_Guards
Persistent Tor Entry Guards Introducion
Current practical, low-latency, anonymity designs like Tor fail when the adversary can see both ends of the communication channel. (edits start)
If an adversary does not control Tor relays, but is able to monitored both ends of the network, a technique called traffic analysis could be used to glean enough information to profile a user. The term traffic analysis is used to described a multitude of different methodologies which can be used to analyze network traffic patterns. Be that as it may, all of those methods fall into one of two categories.passive traffic analysis -
an adversary will extract features from a data stream on one end of the network and then look for those same features on the other side of the network.active traffic analysis -
the adversary alters the timings of packets on one end the the network according to a specific pattern and looks for that pattern on the other side of the network.
Both of the above methods can be used on cleartext as well as ciphertext (encrypted) traffic, and with a greater number of packets observed, the the greater likelihood that information can be extracted from the network traffic which in turn could then be used to profile a user. To put these dangers into better perspective;(edits end) suppose an adversary controls or watches the Tor relay that a user chooses to enter the network, and also controls or watches the website visited. In this example, the research community is unaware of any practical, low-latency design that can reliably prevent the attacker from correlating volume and timing information on both ends.Mitigating this threat requires consideration of the Tor network topology. Suppose the attacker controls, or can observe, C relays from a pool of N total relays. If a user selects a new entry and exit relay each time the Tor network is used, the attacker can correlate all traffic sent with a probability of (c/n)2. For most users, profiling is as hazardous as being traced all the time. Simply put, users want to repeat activities without the attacker noticing, but being noticed once by the attacker is as detrimental as being noticed more frequently. Mathematically speaking, choosing many random entry and exit points to the network prevents the user from escaping profiling by this kind of attacker with end-to-end capabilities.