arma's blog

Thanks to a friend who's a professor at KAIST in Korea, several teams of students there are working for their "freshman design class" on designing new bridge (aka bridge relay) distribution strategies. Here's some early brainstorming on what the actual problems are and what needs doing. read more »

Jake, Mike, Karsten, Sebastian, and I attended Hacking at Random last week in The Netherlands. I did a talk on Tor performance challenges — basically walking through the key pieces of the "Why Tor is Slow" document that we wrote in March.

As usual with European hacking cons, they produced a really well-done video just days after my talk. So if you want to get the highlights on what we're doing to speed up Tor and what roadblocks remain, take a look at the video and also the slides that come with it.

I've just finished writing up an explanation of all the various reasons why the Tor network is slow, and what we can do about each. Part of it comes down to design flaws; some of it is that a handful of users are overloading the network; and there's also simply not enough capacity to go around.

Specifically, we've identified six categories of problems to address, and laid out some steps to resolve each of them.

You can read the pdf here:
https://svn.torproject.org/svn/tor/trunk/doc/roadmaps/2009-03-11-performance.pdf

Andrew has also put together a real live press release to go with it.

Now all that remains is to do everything. So if you want to help, or especially if you know any organizations that can help with funding, please help us make this happen! read more »

Tomorrow there's a talk at Black Hat DC by Xinwen Fu on an active attack that can allow traffic confirmation in Tor. He calls it a "replay attack", whereas we called it a "tagging attack" in the original Tor paper, but let's look at how it actually works.

First, remember the basics of how Tor provides anonymity. Tor clients route their traffic over several (usually three) relays, with the goal that no single relay gets to learn both where the user is (call her Alice) and what site she's reaching (call it Bob).

The Tor design doesn't try to protect against an attacker who can see or measure both traffic going into the Tor network and also traffic coming out of the Tor network. That's because if you can see both flows, some simple statistics let you decide whether they match up. read more »

A growing number of people want to use Tor in low-bandwidth contexts (e.g. modems or shared Internet cafes in the Middle East) and mobile contexts (start up a Tor client, use it for a short time, and then stop it again). Currently Tor is nearly unusable in these situations, because it spends too many bytes fetching directory info. This post summarizes the steps we've taken so far to reduce directory overhead, and explains the steps that are coming next.

First, what do I mean by "directory info"? Part of the Tor design is the _discovery_ component: how clients learn about the available Tor relays, along with their keys, locations, exit policies, and so on. Tor's solution so far uses a few trusted directory authorities that sign and distribute official lists of the relays that make up the Tor network. read more »

One big challenge to making Tor fast is providing incentives for users to act as relays. So far we've been getting more relays by 1) building community through interacting more with relay operators, listing the fast ones prominently in the Tor status pages, and generally making it clear that you will make the Tor network better if you do, and 2) making it really easy to configure and run a relay by adding a simple GUI interface in Vidalia and adding UPnP support. But we should also consider more direct incentive approaches, for example where Tor is faster for you if you're a relay.

There are two papers that came out in 2008 that everybody pondering incentives in Tor should read. The first is "Building Incentives into Tor", a tech report I coauthored with Johnny Ngan and Dan Wallach from Rice University. The second is "Payment for Anonymous Routing", published at PETS 2008 by Androulaki et al from Columbia University. read more »

With the "enforcement" phase of Germany's data retention law coming
into effect on January 1 2009, it's time to start considering design
modifications for Tor to make us more resistant. There are many different
pieces to consider, including

• How should we change path selection so Tor clients are less at risk
  from German ISPs that decide to log?

• What exactly will German ISPs log, and who is supposed to have access
  to it?

• What suggestions should we give to German Tor relay operators, and
  German privacy advocates in general, about how they should fight this
  law without putting themselves too much at risk?

I propose some technical changes to Tor in this or-dev post:
http://archives.seul.org/or/dev/Oct-2008/msg00001.html

Stay tuned for the policy suggestions -- perhaps we'll cover those at 25C3!

There have been a lot of questions today about just what the
recent Debian OpenSSL flaw means for Tor clients. Here's an attempt to
explain it in a bit more detail. (Go read the Tor security advisory before
reading this post.)

First, let's look at the security/anonymity implications for users who
aren't running on Debian, Ubuntu, or similar. These implications all
stem from the fact that some of the Tor relays and v3 directory authorities
have weak keys, so the Tor network isn't able to provide as much anonymity
as we would like.

The biggest issue is that perhaps 300 Tor relays were running with
weak keys and weak crypto, out of the roughly 1500-2000 total running
relays. What can an attacker do from this? If you happen to pick three
weak relays in a row for your circuit, then somebody watching your local
network connection (or watching the first relay you pick) could break all
the layers of Tor encryption and read the traffic as if they were watching
it at the exit relay. read more »