How does Tor encrypt and route internet traffic between my device and the destination?

1. How a circuit is chosen and constructed

When a Tor session starts the client downloads a signed directory of available relays and their public keys from directory authorities, then selects a sequence of relays (commonly entry/guard, middle, exit) and builds a circuit to them; the client negotiates ephemeral keys with each relay so that only those relays can unwrap the corresponding layer of traffic for that hop ^{[3] [6]}. The client’s choice and the directory signatures are intended to prevent on‑path attackers from tricking the client into using malicious relays unless they can subvert directory authorities ^{[3] [6]}.

2. The layering of encryption — why “onion”

Before sending traffic the client encrypts the payload multiple times: the outermost layer is for the entry node, the next for the middle relay, and the innermost for the exit; each relay peels exactly one layer to reveal where to forward the packet next, preserving that relay’s ignorance about the full path and payload ^{[4] [5] [2]}. Those nested layers provide forward secrecy because the client and each relay establish ephemeral keys per circuit that are discarded when the circuit ends, preventing later compromise of a relay from retroactively decrypting past traffic ^{[3] [6]}.

3. What happens at the exit — plaintext, TLS, and risk

The exit relay removes the final onion layer and forwards the traffic to the destination on the regular Internet; if the application data is not protected by end‑to‑end encryption (for example plain HTTP), the exit node — and anyone observing between the exit and the destination — can read or modify that content ^{[5] [7]}. To protect confidentiality from exit‑node snooping, users must use end‑to‑end protections like HTTPS or application-level encryption; Tor’s network encryption only guarantees confidentiality inside the Tor overlay, not necessarily between the exit and the destination ^{[5] [7]}.

4. Limitations and attack surfaces

Tor’s distributed design means no single honest relay sees both origin and destination, but coordinated attacks — such as an adversary controlling both the guard and exit for a circuit or performing global traffic correlation — can deanonymize users; academic and technical overviews warn that timing and volume analysis, relay compromise, and guard selection weaknesses are real risks ^{[4] [5]}. Operator mistakes, malicious exit operators, and the possibility of compromised directory authorities or large relay deployments also create practical vulnerabilities despite the protocol’s cryptographic safeguards ^{[3] [4]}.

5. Cryptographic key management and directory trust

Tor uses a mixture of long‑term identity keys, signed directory information from a small set of directory authorities, and ephemeral circuit keys negotiated between client and each relay to provide authentication, integrity, and encryption; these measures aim to prevent relay impersonation and ensure clients build circuits to the relays they intended, while discarding ephemeral keys when circuits close to limit exposure from post‑compromise inspection ^{[3] [6]}. The trust anchor is the signed consensus: unless the majority of directory authorities are subverted, clients receive a consistent view of the network ^{[3] [6]}.

6. Practical takeaways

Tor encrypts data in layered “onion” form and routes it through volunteer relays so that only the entry knows the user’s IP, only the exit sees the destination, and intermediate nodes see only neighbor addresses — but this does not eliminate the need for application‑level encryption, nor does it make users immune to sophisticated correlation or compromised-relay attacks; the Tor Project’s documentation and multiple technical surveys outline both the strengths of the design and its remaining operational limits ^{[1] [3] [4]}.