Running a guard node (aka an entry node) is safe for the person running it. The reason there aren't as many of them is because there are certain criteria that must be met before your relay can be used as a guard node:
The relay needs to have first appeared longer ago than 12.5% of the relays, or 8 days ago, whichever is shorter.
The relay needs to advertise ...
As a start, this script (see below) will grab a list of nodes from this website (or update the list if it's >30 minutes old) and display them. You should be able to fetch them from any directory server as well, but I'm not entirely sure how. You'd have to look at the dir spec.
As of posting this we have:
369 relays that ...
All Tor circuits contain 3 nodes by default (passing over hidden services which work a little differently and essentially use two circuits chained to a gateway node). Any more than this does not add any extra anonymity.
While it is possible to change the number of nodes by modifying the source code, this is not recommended. Any less than three nodes and ...
When running an exit node, it is highly recommended to make it as clear as possible that it is an exit node. This helps the operator deal with DMCA notifications and abuse reports and the like.
Further more, it is impossible for any relay, exit or non-exit, to hide the fact that they are a relay. The list of all relays and their flags is publicly available....
Caveat: not a complete answer, but still a start:
There probably is a limit, given Tor's current design. For instance, right now it's assumed that every relay can and does talk directly to every other relay. Once you have many tens of thousands of relays that just won't work anymore.
For now, Tor has kept ahead of the curve. However, this requires ...
If you are looking to be able choose a specific entry nodes for specific period of time you may open the torrc and insert the following line:
On restart of Tor it will use the entry nodes if available.
The rules for selecting nodes can be found in the path-spec. Specifically in §2.2 Path selection and constraints.
A few points from the section:
We do not choose the same router twice for the same path.
We do not choose any router in the same family as another in the same
path. (Two routers are in the same family if each one lists the other
Another bottleneck is the distribution of the network consensus. To maintain anonymity, every client must have the full consensus for relay selection. As more relays and users join the network, the distribution gets more and more expensive. After all, every relay adds another entry to the consensus and every user will periodically want to download the ...
The whole Tor network advertises 6 GiB/s according to the metrics page. DE-CIX statistics say they have an average bandwidth of 200 GiB/s. So if you assume that web traffic is roughly 20% of all traffic, we talk about 40 GiB/s. Numbers between 5 and 30% are 2 to 12 GiB/s of traffic in the DE-CIX case.
So if those estimation is correct, Tor should be able ...
I will add that these statements are within the confines of the protocol. As you mentioned in your question/comment, a single node could use outside resources to determine entry and exit points. However, the number of hops between the two cannot be determined. The middle nodes only know that they're talking to other nodes within the Tor network, without ...
so I guess the entry node is limiting the traffic if you make too much traffic, right?
The long guard rotation period is for security reasons. The more often you pick a new guard, the higher the chances that you will encounter a bad one (i.e. owned/controlled by the party you want to hide from).
See also: Changing of the Guards and One Fast Guard ...
If you're using a version of TBB without Vidalia and don't want to install Arm or other control software you can get this information directly from the control port. First you'll want to get the authentication string to use from the auth cookie (this is where it's stored in the TBB, if you've got Tor installed on your system some other way you'll have to use ...
This information have traditionally been available in Vidalia, the graphical controller that used to come with TBB (Tor Browser Bundle). Since TBB 3, Vidalia have however been replaced with Tor Launcher, the latter which still is missing information about which Tor nodes are being used.
What you instead need to do until this functionality is implemented in ...
You can use arm for this purpose. arm is a command line program and it shows several information about the current running Tor instance. When you use the Tor Browser Bundle 3.5 you should enter the following command:
arm -i 127.0.0.1:9151
The TBB uses port 9151 by default. When the program has started you'll see an overview of the bandwidth usage. The ...
Yes, Tor clients encrypt connections to entry nodes (relays). Indeed, they successively encrypt to all relays in the circuits that they specify. The required public keys for all relays are available from Tor's directory servers.
Your question is somewhat similar to Getting Tor to randomly use various Country IP's per session.
If you know the name or fingerprint of the node, open the torrc and insert the following line:
When you restart Tor it will use the entry nodes if avalaible.
You can't decide on your own to become a guard node. The Tor software makes the decision. All the details are laid out in Tor's directory specification.
So after you set up your Tor relay, it takes some time until it attracts traffic. Beginning on day 8 of your relay's lifetime it becomes eligible for the Guard flag. However getting the flag depends on the ...
No, and it will never be implemented: it would break the whole relay idea of Tor. Every relay - regardless of it's further roles - is a "regular node", i.e. the middle one. If it's allowed to go outside - then it also/additionally receives an Exit flag. If it's stable and not flapping - it receives a Stable flag, if it's stable-flagged and has a decent ...
Here's a somewhat simplified description: When a relay receives an incoming packet, it first decrypts the outmost encryption layer of that packet to see what it's supposed to do with the packet. It finds a command, which can be, among other things, a) "send this still-encrypted packet along the circuit to the next relay" or b) "send this possibly-plain-text ...
The routing used in the Tor network is called onion routing because the mechanism for maintaining anonymity in it is based on multiple layers of encryption which resemble layers of an onion.
Inside the Tor client it is hard-coded that the traffic will pass through three relays: entry node, middle node and exit node. There are multiple layers of encryption ...
First of all, we don't usually refer to Tor instances running as clients as nodes. Nodes are relays, and unless specifically said otherwise, it usually also excludes bridge relays. So nodes are any instances of Tor that are in the public consensus.
For introduction points, tor picks nodes that are stable (which was previously called having high uptime).
approximately how many distinct Tor circuits are possible?
This deppends greatly in the amount of nodes available at given time and the possible combinations, but there isn't a fixed number that won't be obsolete the next time you calculate this. Tor normally is run by well stablished nodes, but if the amount of nodes change rapidly calculate this could ...
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 ...
Those specs don't include CPU speed, number of cores, network speed. 512MB of RAM may be a bit tight.
You can use the following directives in your torrc to influence the bandwidth usage of your relay:
RelayBandwidthRate - Limits the average incoming bandwidth usage for relayed traffic on this node to the specified number of bytes per second.
As you already wrote in your comment you can set FascistFirewall 1 in your torrc. Tor will then use the ports 80 and 443 for outgoing connections to the first node.
The options FirewallPorts is marked as deprecated in the manual. So don't use this option. But you can use ReachableAddresses (see The ReachableAddresses version of FascistFirewall for details).
Yes. An attacker can perform a sybil attack or just kick down your guard node repeatedly until your Tor client choose a malicious node as guard.
Controlling your guard node doesn't lead to decrypting your traffic, but mostly makes you vulnerable to traffic correlating or path bias attacks, thus makes tagging attack and eavesdropping possible.
See Should I ...
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 ...
Tor does not let you decide whether to be a Guard or not by yourself. Since there are many security concerns with the Guard node, Tor has very strict conditions to flag a node as Guard node.
For your ready reference, you can look at session "5. Guard nodes" of this Specification file.