1

I'm a bit confused by something regarding Tor. As per what I have read and confirmed in this answer Tor: Is a Diffie-Hellman key exchange being done over recipient of traffic? the client does a DH key exchange with each node in the relay.

This results in 3 shared secrets and the client encrypts the message 3 times with each different key.

To decrypt the node uses its shared DH key to peel off a layer.

Problem is that the node must know which DH shared secret to use as I assume there are many clients doing this and the node may have many of these. So in order to use the correct shared secret it needs to know which DH exchange this specific message is for and it can then know the sender.

What an I missing?

Thanks, Chris

Bruno Rohée
  • 5,351
  • 28
  • 39
Chris Owen
  • 13
  • 2

1 Answers1

3

The key exchange between a client and a relay is not done directly but is wrapped in the onion layers like any other communication: A connection ("stream") through the Tor network gets first build to the first relay, then through this first relay extended to the second relay etc.

This means that the relay will only have an association between a stream and a key, but not an association between a specific sender and a key. All it knows it that the same short-lived stream is associated with the same sender, but not who the sender is.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • "The key exchange between a client and a relay is not done directly but is wrapped in the onion layers like any other communication"....... I dont understand how this is possible, in order to build up the onion layers keys need to be exchanged to encrypt each layer. If you are saying that the key exhange is also wrapped in onion layers then how those keys created for this? – Chris Owen Dec 28 '21 at 11:29
  • "Tor network gets first build to the first relay, then through this first relay extended to the second relay etc."... Can you explain this further, the linked SE answer states that keys are exhanged between client and each hop – Chris Owen Dec 28 '21 at 11:30
  • 2
    @ChrisOwen: client connects to relay A and does a key exchange with A. Then client connects through A to relay B and does a key exchange with B. B sees only that the connection comes from A, not from the client. Thus while the key exchange is done logically between the client and each relay, the relay only sees the previous relay as the physical origin (IP address). – Steffen Ullrich Dec 28 '21 at 12:00
  • Ok but in this case B must return there key in plaintext as the shared secret has yet to be established between client and B. At this point what is stopping A sending some other key back instead? – Chris Owen Dec 30 '21 at 04:05
  • @ChrisOwen: Diffie Hellman key exchange is designed to work over untrusted channels. Keys are never transmitted, but both sides derive a common key based on the exchanged data. The most A could do is disrupt the communication. – Steffen Ullrich Dec 30 '21 at 06:00
  • @Steffan when I say "Ok but in this case B must return there key in plaintext" I mean the shared data (i.e. the X25519 public key etc) not derived DH secret. Obviously the derived secret would not be exchanged.. So when you say "The most A could do is disrupt the communication". Hence can the not provide the shared DH data as if they were B, this way the are able to derive both there shared secret for the first layer and the one intended to go to B? The only way I can think around this is B also signs the response which Bob can verify it did indeed come from B via A. – Chris Owen Jan 03 '22 at 07:07
  • @ChrisOwen: So you are asking if node A can be an active MITM on the key exchange between the client and B, i.e. causing it to exchange different keys between client and fake B (i.e. A) and A and real B? You are right that some kind of authentication is needed to protect against this - see [How does Tor protect against MITM attacks between the client and relay nodes](https://security.stackexchange.com/questions/215155/how-does-tor-protect-against-mitm-attacks-between-the-client-and-relay-nodes). – Steffen Ullrich Jan 03 '22 at 07:11
  • Exactly, thankyou I thought I was going crazy there for a second, this clears things up for me thankyou for you time. – Chris Owen Jan 03 '22 at 07:33