Me -> Node A -> Node B -> Node C -> destination

The documentation on Tor always states that only the exit node C can see plain text data. How is this possible without me talking to Node C directly?

If I have some plain text data, and want to send it encrypted to Node A, I'd usually do a Diffie-Hellman key exchange, and send the data over. But with that scheme, Node A could decrypt the data.

If Node C was somehow sharing its public key with me, couldn't Node B or Node A MITM the key?

How exactly does Tor manage its PKI? What keys are used to encrypt data where?

  • This Answer gives a slightly different analogy. In answer to your question: Node C is able to open the red box, in which is contained the plain text 'Nasty Letter'.
    – lynks
    May 28, 2013 at 16:20

3 Answers 3


Tor uses a routing method called Onion routing. Much like an onion, each message (the core of the onion) is covered with layers of encryption. attrib:wikipediaimage attribution

Your message is encrypted several times before it leaves your device. Node A can only decrypt (peel) the layer A, under which it would see the address of the next node. After the packet reaches the next node, it can only decrypt (peel) layer B, and so on. For each layer, you use the respective node's public key, so only that exact node can decrypt the layer with its own private key.

When the message reaches the exit node, all of the layers have been decrypted and message is now in plaintext (it could also be encrypted if you're communicating with the server under SSL).

  • 19
    Bloody marvelous image, looks like a nuclear reactor core with a fuel rod inserted into it!
    – TildalWave
    May 28, 2013 at 15:34
  • 2
    +1 just for the image. I've been looking for a good visual representation of Tor onion routing for a long time.
    – Polynomial
    May 28, 2013 at 16:09
  • 3
    @PeteyB There is no "return trip". The routing creates a TCP connection chain, which is full-duplex.
    – Polynomial
    May 28, 2013 at 16:16
  • 4
    I agree with Petey B, the return path of the TCP connection is kind of "hand waved" away. Could you update your answer to give a better explanation of how a reply packet (even something as simple as the SYN-ACK packet of the 3 way handshake) on the TCP connection is sent back through the tor network and get to the original sender? May 29, 2013 at 0:44
  • 2
    @ScottChamberlain There is no end-to-end TCP connection. Tor handles data in logical Streams, so each hop is free to fragment or combine data as it sees fit (though for intermediate hops this would likely break the crypto). In other words, the client only establishes a TCP session with the first hop. Everything from there out is a Stream, just like using a SOCKS proxy. Jun 23, 2013 at 0:44

TOR uses the principle of onion routing. Let us say there are 3 TOR nodes A,B and C involved (selected randomly by client) and the message is m. We assume the corresponding public keys of these nodes to be Pa,Pb and Pc.

The message is repeatedly encrypted by the client starting with the public key of the exit node (Pc) followed by Pb and in the end Pa (Onion Routing).

Data received by node A: Pa(Pb(Pc(m))) 
Data received by node B: Pb(Pc(m)) 
Data received by node C: Pc(m)  

The data is decrypted at each node by using their corresponding private key. After decryption each node gets some plain-text information about where to forward the remaining data. This makes sure that no single node knows the entire path. Each node only knows about the previous and the next node.

p.s. There is a very good article on TOR in our community blog but somehow I am not able to find it. If anybody finds the link please add it to the answer.

  • +1 for the pseudocode. Makes it much clearer.
    – Adi
    May 28, 2013 at 16:07
  • Commenting on both answers for visibility: Okay so TOR relies on a PKI directory to hold all public keys? The public keys for each router are pulled by the client and used to encrypt the data. How about on the return trip? Does the exit node pull all keys down from the directory and perform the same operation in reverse? How does router C get the client public key? Are client keys stored in the PKI directory as well?
    – Petey B
    May 28, 2013 at 16:11
  • @PeteyB router C does not need the client's public key.The onion routing involves the public keys of the nodes and not the client. as mentioned in another comment a TCP connection is created by routing.
    – Shurmajee
    May 28, 2013 at 16:20
  • 1
    @MayankSharma Maybe I'm being silly: So how are packets encrypted on the return path? If they're simply encrypted with the nodes' private keys, then any packet caught between two nodes could be decrypted rather easily by anyone with a snapshot of the node pubkeys at that time?!
    – us2012
    May 28, 2013 at 23:11
  • 1
    @us2012 The crypto involved is TLS. Public-key crypto is only used to establish a symmetric session key between two endpoints. When the whole chain is complete, the client has separate TLS connections with each of the 3 hops, most of which are tunneled through the others. Jun 23, 2013 at 0:49

There are two different question here :
1- how do we send data and how nodes decrypt each layer of encryption?
2- how do we get data from exit node?
About first question, I can say there is no public key encryption for sending data to destination, But Shared Secrets. Before this you should know enough about D-H.
D-H steps:

  1. Alice and Bob agree on a finite cyclic group G and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) We will write the group G multiplicatively.
  2. Alice picks a random natural number a and sends g^a to Bob.
  3. Bob picks a random natural number b and sends g^b to Alice.
  4. Alice computes (g^b)^a.
  5. Bob computes (g^a)^b.

After these steps Alice and Bob have a Shared Secret s and no one knows about this Shared Secret.

Tor Steps :

  1. OP(onion proxy or source) sends g^a to Node1(onion router).(but encrypted by Node1's public key)
  2. Node1 decrypts data with private key and then sends g^b to OP.(in clear text. because if OP's public key known to ORs then where is privacy!!).
  3. Now OP and Node1 have a Shared Secret.[e.g: SS1 = OP & Node1 = 2].
  4. OP sends g^a to Node1 which Node1 should send that to Node2.('a' is a new random number)
    OP encrypts g^a with Node2 Public Key, and encrypts data(en(g^a) and Node2 address) with SS1.
  5. Node1 decrypts data with SS1 and gets Node2 address, and sends remaining encrypted g^a to Node2.
  6. Node2 decrypts data with her private key, and then sends g^b to Node1 again.(clear text)
  7. Node1 encrypts g^b with SS1 and sends to OP.
  8. OP decrypts data with SS1.
  9. Now OP and Node2 have a Shared Secret which Node1 doesn't know.[e.g: SS2 = OP & Node2 = 5].

This will be continued until the circuit complete.now OP can send request for destination through Nodes with (SS1, SS2 , ...). last sending request should be like this :

OP to Node1 => encryptSS1(send to Node2, encryptSS2(send to destination, "hello server"))

And about second question receiving response should be like this :

  1. Dest to Node2 => "hello client"
  2. Node2 to Node1 => encryptSS2("hello client")
  3. Node1 to OP => encryptSS1(encryptSS2("hello client"))
  4. OP decryptSS1(decryptSS2(data)).

Take a look at an image on this page :
Onion routing - pikneek

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .