Return to the index of lecture notes
April 19, 2011 (Lecture 23)

Anonymous Routing

We've talked about Kerberos. It provides us with a way to authenticate our identity to various services. It also provided us with a way of negotiating a session key to use to ensure the privacy of our communication with those services.

Today, let's look at something slightly different. Let me ask you this, if your communication is encrypted, is your privacy protected? It isn't really protected if someone watching the bytes fly by knows to whom you are speaking and when, is it? Remember that routing involves unencrypted headers that contain source and destination information.

Today, we are going to explore anonymous routing, techniques for routing that protect the identity of the sender and the receiver.

What Do We Need?

We a way of sending a message from one machine, to another machine, without anyone in the middle knowing from where it came or to whom it is going. This is almost possible. The first node is going to know where it came from. And, the last node is going to know where it went. But, the nodes in the middle, can be like the random long path from point-A to point-B, as much to generate confusion as to get from one place to another.

If I were taking you for a drive and wanted to keep the location secret from you (think CIA safe house), other than blind-folding you, I'd pick the route in advance. It wouldn't be the shortest or simplest path. It would just be confusing. And, to make sure no one accidentally told you anything, I might you a bunch of different taxis, each one just knowing to get you from Point-A to Point-B, not where you were eventually going, nto where you originally came from, and not necessarily even which was the last stop.

And, every time I took someone to the safe house, I'd use a different route and different drivers, so no one figured anything out, e.g. there's usually anther driver waiting over there, or "last stop".

And, of course, if you happened to be carrying any secrets, I'd want them encrypted and inconspiciously hand-cuffeed to your wrist.

How Do We Acheive This In Software?

First, we need to establish the network of taxi drivers. We need a set of nodes that will do this type of hop-to-hop routing for us, accepting messages and forwarding them as needed.

Then we need a way of expressing our route to those among this network of nodes that we choose to use -- without letting them all see it. To do this, we first pick our nodes, and then negotiate with each of them a key to use to encrpyt the messages for their hop. What they get when they decrypt each is another message. The payload is encrypted, but the header is not and gives them the next hop. the last hop hands off the message, either encrypted such that the destination can decrypt it, or not at all.

So, first we pick some arbitrary routing. Then, we negotiate this set of keys with each hop. Finally, we encrpyt the message so each hop can decrpyt it in turn. Now, we send our messge to the first router, and it flies from there.

What we have created here is essentially a virtual circuit. We've set up a path from Point-A to Point-B. But, since we had to negotiate all of these keys, we want to use it for at least a while. So, we send a bunch of messages through before creating an new one. This amortizes the communication cost over time.

But, of course, not too much time. We want to switch routings again fairly soon, so that traffic analysis doesn't show our pattern of traffic through this set of routers.


The system as described above is essentially tor. In addition Tor offers anonymous roundezvous services. In other words, it allows clients and servers to connect anonymously to each other using the anonymous Tor network to generate a virtual meeting place that is not at either system.

Beyond Tor

Tor hides the actual routes. And, it uses virtual circuits for only about 10 minutes, to balance the amortization of the cost with the desire to keep things changing.

But additional levels of protection might be needed against determined adversaries. For example, traffic analysis might show that the source, the destination, and certain linkes are "hot" at certain times. Or, certain timing artifacts might be noticed at one node and observed at another.

To combat this problem, it is possible one can generate a bunch of bogus traffic to dilute the real traffic. One can also bundle messages together somewhat arbitrarily at the various nodes, only unbundling them later to mix the traffic streams. It is also possible to have the various routing nodes introduce random timing artifacts, such as jitter, delay, or reordering.