How does a Tor exit node know the public key of the client?

Question

When the Tor exit node executes the client's request and receives a response from the server, it must create an onion cell that can be reversely decrypted along a circuit through the Tor network. Thus, the client must be the last one to decrypt, otherwise the contents of the request can be linked back to the client's IP by the first intermediate (bridge) node, breaking anonymity. Therefore it seems the exit node would need to first encrypt the response from the target server with the public key of the client -- therefore the client will be the only one that can decrypt and get the plaintext response.

However, how can the exit node encrypt with the public key of the client? If it had this knowledge wouldn't it be able to determine the identity of the client?

Answer 1

The client uses Diffie-Hellman to negotiate a session key with each node when establishing a circuit. This is done incrementally, so each DH handshake (after the first) is routed through the existing partial circuit.

https://svn.torproject.org/svn/projects/design-paper/tor-design.html#subsubsec:constructing-a-circuit

So, the exit node has a shared session key with someone, but doesn't know who.

Note also that the exit node does not add multiple layers of encryption to the response like the client does for the request. Rather, the exit encrypts the response with the session key for the client, and sends it back to the previous node in the circuit, which repeats the process. When it finally reaches the client, a layer of encryption has been added at each node, by that node. The client has a session key shared with each node, so it can peel back all the layers.

Answer 2

The exit node doesn't need to know the public key of the client, because they operate on symmetric keys.

Tor's design document has a section where it describes how circuits are built.

1. The client (called onion proxy) sends a CREATE packet (or cell in Tor terms) to the first relay. It uses Diffie-Hellman key exchange to construct a symmetric key.
2. The first relay finishes the key exchange and sends a CREATED cell.
3. The onion proxy uses the first relay to extend the circuit to a second relay and sends a RELAY EXTEND cell. This also contains informations for a DH key exchange.
4. The second relay sends a CREATED cell back and onion proxy/2nd relay share a symmetric key
5. The same is done with the next relay.

In the end the onion proxy shares different symmetric keys with all three relays. When the exit relay receives data which is intended for the onion proxy it encrypts it with the shared key. It sends it to the previous relay who also shares a key etc.