No, you shouldn't pick a new guard. Your guard is still working. If it doesn't handle any circuits, Tor automatically shifts to a different one. You should let Tor do its path selection.
Those messages are new in Tor 0.2.4.x, and the goal is to help detect anonymity attacks called "path bias attacks".
You can read more details at Ticket 5458, but the basic ...
This has been described in details in the phase three of The lifecycle of a new relay.
Your new relay has to be stable (up and running for at least 8 days), and have a minimum bandwidth of 250KB/s to receive a guard flag and become an entry node.
Here I quote from Tor spec:
A router is a possible 'Guard' if its Weighted Fractional Uptime is at
The short version is that when your adversary owns your first and your last hop you lose.
Assume you have an adversary that controls a couple of nodes.
You change your last hop all the time. If you also change your first hop all the time, they'll find you sooner. If you pick it once and then stick with it you either picked badly, and you lose, or you were ...
The short version is: If you happen to be an entry node for a hidden service, and you connect to that same hidden service, you can tell you're its entry node (and what its IP is) by correlating the traffic you're sending to the hidden service with the traffic you're sending to a client (which is the hidden service).
If hidden services didn't use guards and ...
Currently not every fast exit is also assigned the Guard flag. There was a change reported at TWN of July, 30th 2014:
Once directory authorities have upgraded, they will “assign the Guard flag to the fastest 25% of the network”. Some experiments showed that “for the current network, this results in about 1100 guards, down from 2500.”
If I'm correct the ...
Each authority votes on what they think the proper flags are for your relay.
Currently it seems 5 think angrykitteh should have the Guard flag, and 4 think it shouldn't yet. Depeding on which authorities manage to vote for which consensus, the flag might end up being set in the consensus or not.
I suppose in a while the remaining 4 authorities will also ...
Currently Tor chooses 3 entry guards. There may be much fewer entry guards than Tor users, but as you fear, when combining 3 randomly chosen entry guards they indeed become a unique fingerprint for you. At least very very few users have the same set of entry guards as you do, and probably no one else at your geographical location.
It will be very easy for ...
Third, how does one reconcile the apparent desirability of maintaining guards (and, therefore, presumably a session) with the "don't mix identities" warnings.
I believe you are mixing two concepts here. Guard relays protect your connection to the Tor network. The "identities" (Frank and George) are presumably id's on web pages, and as such only visible in ...
The Tor spec says:
5.3. Creating circuits
When creating a circuit through the network, the circuit creator
(OP) performs the following steps:
Choose an onion router as an exit node (R_N), such that the onion
router's exit policy includes at least one pending stream that
needs a circuit (if there are any).
Choose a chain ...
The guard flag is only given to servers that are sufficiently fast and stable [dir-spec]. Stable means being available most of the time.
So yes, if your relay goes down due to hibernation this can result in your relay not getting the guard flag next time it becomes available. Clients will deal with this and just pick new/more guards.
I am not aware of ...
Your question is two fold. So :
1) "get into my traffic and find out my location" For this, you need tor. Install Orbot from f-droid.org client.
2) "see what I was saying" For this, you need something like OTR or any other end-to-end encrypted protocol like axolotl.
2.a) Install a chat client with OTR support. Install Chatsecure from f-droid.org client. ...
Also all my circuits are now being built by zwiebelringrexlocus
My circuits no longer seem to be popping around different connections and cities... whats happened?
zwiebelringrexlocus is your (new?) guard node. It is normal and by design that you keep using the same guard for a long time.
The 2nd and 3rd node in your circuits are all different. You do ...
Even if you got this to work, it wouldn't benefit the Tor network. Proxies tend to be slow and unreliable, so your relay would be as well.
Also, a Tor relay wouldn't go unnoticed for very long. Few students are online 24/7, as the relay (with luck) would be. And given your comment about the admin, you would soon be in trouble.
You could use your own ...
Tor is the 2nd generation of onion routing. In onion routing, the message is encrypted multiple times with a different key for each layer of encryption. In Tor as long as Alice (the client) has established a circuit with 3 nodes, the entry node, the middle node and the exit node, that means that the original message to Bob(the destination) will be encrypted ...
It's a tradeoff between security and connectivity. If you happened to pick a slow guard, you can pick a new guard to improve connectivity. Doing so would decrease security, because guards are fixed for a reason. Changing them when someone may want you to change them is a bad idea.
You can find the advertised bandwidth values in the bandwidth.csv file, which is linked below each metric graph.
As explained on the Tor Metrics Portal: Statistics page, each row of this file has the following fields:
The rows where isguard column is t(rue) will give you the bandwidth for the ...
First, I assume (please tell me if I correct or not) that a new set of guards is selected each time a user initiates a Tor session
That's incorrect. Tor stores the details of the guard nodes it used during its last session. Unless the appropriate time period has elapsed, it will reuse the cached ones when it next starts up.
Tails, due to its non-persistent ...
Tor is only used for tunneling TCP packets. By default traceroute sends UDP or ICMP (Internet Control Message Protocol) packets, ergo it can't be routed through Tor.
However, it's also possible to send TCP SYN's to do essentially the same thing. If you used traceroute to print a series of SYN-ACK's, you would see the path from the exit node to the final ...
How is this adversary figuring out what entry guards you are using?
Assuming it does from you connecting to Tor on an access point owned by them.
There are more Tor users than entry guards, so one entry guard is used by multiple people which will help with matters.
Also, how is he logging where data from the entry guard is going? (this is just a ...
It depends on the threat model.
When one assumes an passive adversary keeping logs to which entry guards one is connecting to and when one plans to use Tor from different internet access points, it might be better to have non-persistent entry guards. This question Tracking User Location using Entry Guards? wheter this may or not be the case.
When one ...
You can find your EntryGuards in your data directory. If you are using the Tor Browser Bundle, you have the list in Data/Tor/state. In other cases there will be a .tor directory in your home directory or similar.
Currently Tor selects 3 EntryGuards per default. This setting may however be changed using NumEntryGuards. There is another option that is called ...
Bridge, is designed to act as entry node (guard). There is no difference as far as number of hops with or without bridges when you connect to a given server. If there were three hops required to connect to given server without a bridge, there are three hops required to connect to a given server with a bridge. This include the bridge as a first of three hops ...
First of all: As far as i know, if you do not compromise the Entry-Relay (Guard), you can not locate the client. So being said, the third case does not result in client de-anonymization.
For the other two cases, in which you have compromised the entry-relay, you will be able to locate the client.
To be a little more specific:
Before there were Entry-Guard ...
I am in the same situation. My relay is jobiwan. Guard flag has been wild lately.
I believe this happens when your bandwidth is just about enough to be guard. The authorities vote 4 against 5 or 5 against 4 and small fluctuations in your consensus weight fraction can flip the balance.
You know that some rogue entry node isn't faking Tor circuits because your Tor client specifies the relays used in each circuit, and because the circuit-creation process requires that each relay demonstrate that it possesses the proper private key. In order to mount such an attack, an adversary would need to compromise most Tor relays, in order to get their ...
TL;DR The answer will depend on what you consider important, and what your Tor use-case is. (Similar to the hand-waving over threat models mentioned in another answer.)
However, in general, the recommendations would be to:
Use fewer guards;
Keep the guards for longer.
These are described in Part 3 of a post on the offical Tor blog, which references 3 ...
Proposal 236, which has been implemented by now, explains the behavior:
When this proposal becomes effective, clients will switch to using
a single guard node.
That is, in its first startup, Tor picks one guard and stores its
identity persistently to disk. Tor uses that guard node as the first
hop of its circuits from thereafter.
If that ...
Do Tor authority servers, or probing servers, or those clients who were dropped by the malicious guard have any mechanism to report it to the authority servers so that the malicious guard will be rejected in the next consensus vote?
Malicious relays should be reported to email@example.com, along with the malicious activity, the fingerprint of ...