The Tor FAQ also tries to answer this, but here's my attempt :
Circuits get created on start-up and whenever Tor thinks it might need more in the future or right now.
Once a circuits is actually used for the first time, it'll be marked dirty. Dirty circuits are used for new connections for 10 minutes by default (see MaxCircuitDirtiness in the manual).
Taken from Tor Path Specification document:
We choose the path for each new circuit before we build it. We choose
the exit node first, followed by the other nodes in the circuit. All
paths we generate obey the following constraints:
We do not choose the same router twice for the same path.
We do not choose any router in the same family as ...
Tor uses fixed cell sizes. The design document states:
Traffic passes along these connections in fixed-size cells. Each cell is 512 bytes, and consists of a header and a payload.
Apart from that no further mixing or randomisation is used:
No mixing, padding, or traffic shaping (yet): Onion Routing originally called for batching and reordering cells as ...
I want to add some details to alaf's answer:
A Tor circuit consists always of three nodes. Longer paths may hurt your anonymity in the case of Tor.
Exit node is chosen.
Your torrc might have some settings about which exits to (not) choose.
Tor chooses an exit relay which actually allows you to exit the Tor network. Some only allow web traffic (port 80) ...
Nodes in circuits are chosen randomly. (Selection is weighted by a way-too-complex function of capacity, roles, etc, but it's still a random selection.)
Sometimes, two random choices will actually be the same, just like sometimes a coin toss will indeed be heads-up twice in a row.
That means that every once in a while a new circuit will exit from the same ...
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 ...
Setting up circuits is very expensive. It involves several round trips, and it involves lots of public/private key operations for the servers.
Continually creating new circuits at a high frequency is wasteful and thus quite abusive. Please don't do it.
[ Tor user <-> Guard node <-> Middle node <-> Exit node <-> Server ]
Sending data to server:
The Tor client always encrypt the data for the exit node
And then encrypts it again (another layer) for the middle node
And then again (yet another layer) for the guard node
This way one layer need to be peeled of at each hop in the ...
Requesting a NEWNYM over the control port will tell Tor to consider the currently used circuits "dirty" (this normally happens after 10 minutes, with a few exceptions), at this point it will no longer attach new streams (connections) to the "dirty" circuit, and instead will attach them to a "clean" circuit (it doesn't normally build a fresh one at the time, ...
Tor puts many streams onto a single circuit. If possible, the same circuit is used for up to 10 minutes -- see For how long does a circuit stay alive? for some details.
Accordingly, if you visit a website and it takes a hundred http connections to fetch it all, Tor will use the same circuit for all of that. If you stay on the website for a while and load ...
During the time when you encountered this fluctuation Tor had some problems with a botnet. Some ukrainian guy deployed Tor nodes and they build cuircits. As there were quite a huge amount of clients, this put a fair share of load on the relays. Maybe your relay also was affected.
This fluctuation should have disappeared because tried to remove the malware.
It's complicated. There are many reasons Tor builds circuits preemtively: access hidden services, provide them, exit to any ports that you may want to use (based on recent behavior) and also measuring the network to determine what latency/circuit build times to expect.
circuit_predict_and_launch_new() has all the gory details.
No. Tor traffic does not necessarily all exit at the same exit node.
For each socket connection that the client sets up, a circuit is used that ends in an appropriate exit node. That is an exit node that allows the IP and port the client is trying to reach.
From the §2.2 "Path selection and constraints" of the Path Spec (as of commit 6f2919a2):
Additionally, we may be building circuits with one or more requests in
mind. Each kind of request puts certain constraints on paths:
All service-side introduction circuits and all rendezvous paths
should be Stable.
All connection requests for ...
The other answers give an overview of what happens, but if you want to learn the consequences of the path selection algorithm you need to have a simulation based on real data. Fortunately there now is one – TorPS which was written for the paper "Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries".
The ip of the exit relay does not say anything about your identity. The whole circuit is replaced, not (just) the exit relay, so it shouldn't matter if you end up on the same exit node.
As for theTorbutton vs Vidalia new identity, the Torbutton additionally clears out your browser's session cookies, cache, history, etc and closes open tabs. Vidalia just ...
Tor often builds circuits well in advance of actually needing them. This speeds up various operations since building circuits are quite expensive and time consuming. Circuits it has build are earmarked for a specific purpose, say making exit connections out of the Tor network.
If Tor wants to do some specific operation (say connect to an introduction ...
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.
Regarding the question "Can you be arrested?", yes, you can be arrested all the time. In most countries you can be arrested for looking funny at a police officer. In most countries you will also be released as soon as they have no reason to suspect you anymore. Interesting questions would be would a prosecutor charge you and would those charges hold up in a ...
You can download a standalone version of Vidalia if you are on Linux or Windows.
For Windows the extension is .exe and for Linux it is .tar.gz for Vidalia. .asc is the signature file to check the integrity of the standalone Vidalia bundle.
Then you have to extract the Vidalia bundle to some folder you can write to. It is not recommended to use the folder ...
Right now Tor has no support for splitting connections over different circuits.
While, technically, support could be added if we had a design and the manpower to implement it, it's at this time not entirely clear if it's a good idea. The performance and anonymity implications have not been studied sufficiently.
Circuit on-demand are purposely to replace the previous circuit if the relays selected initially are bad, unstable, lower bandwidth/throughput, congestion, attackers relays etc.
In addition, if the Tor client uses the same exit node and configured to use the same circuit, then the streams from many websites will passes through the same circuit. Else, in any ...
Functions for node selection and circuit construction can be found in routerlist.c and circuitbuild.c files in src/or directory. Possibly the most relevant ones are the following:
Yes, that's correct.
There are two types of circuit handshakes -- the original, called the Tor Authentication Protocol in Ian's paper about it:
and then the better one, called NTor:
Introduction and Rendezvous points are only used for Hidden Services. The Introduction point is chosen by the Hidden Service and published with the HSDir servers handling the Hidden Service. When a user wants to connect to the Hidden Service, they randomly choose a rendezvous server and ask the Hidden Service (through the introduction point) to connect ...
Nice timing, we just expanded our tutorials around this! For this you should use new_circuit() and attach_stream() rather than NEWNYM. For an example of doing this see...
Ok, I figured this out. For some reason the custom onion address I made with Shallot was no longer working. I made a new hidden service and got rid of the existing one, restarted Tor, and voila! I'm not sure why this happened, but this solved both hidden services that had stopped working.
The type of attack you are describing is a congestion attack. In theory, the simplest form of such an attack would be a general DoS on the Tor network.
Taking things one step further, a congestion attack could be used in conjunction with traffic correlation to monitor a given user of the Tor network. Such a strategy is discussed in A Practical Congestion ...