arma's blog

On Friday (Aug 27), I attended the "Workshop on Cyber Security Data for Experimentation" organized by the National Science Foundation (NSF). The premise of the workshop was that many academics need real-world data sets to solve problems, whereas industry is the place with the real-world data sets and they don't have any real reason to share. By getting the academics and the industry people talking, with government funders nearby, they hoped to better understand the problems and maybe move things forward.

I was there (and on the first panel) because of Tor's work on gathering Tor network snapshots, performance data, and user statistics. Tor's approach represents one way out of the trap where researchers never quite get the data they want, or if they do it isn't open enough (which hinders whether anybody else can reproduce their results). read more »

On Sunday (8/22) through Wednesday (8/25), I visited the Tor research group at UCSD as part of my ongoing plans to help academic research groups better understand Tor and its research problems. Damon McCoy has a fellowship (postdoc) there for last year and this coming year, and he's brought Kevin Bauer in from UColorado from now until December. They have two systems profs with congestion control background (Stefan Savage and Geoff Voelker) interested in helping them work on Tor and performance.

Kevin is planning to spend the next year on Tor performance work, as the last chapter of his thesis. He's also applied to Ian Goldberg's postdoc position at Waterloo. He seems like a smart and dedicated guy; I'd be excited if Ian picks him.

I spent most of my time walking Damon and Kevin through Tor's current congestion control levels -- explaining what Tor does, as well as what I think is actually resulting from each of these components. Kevin has lots of notes, and if all goes well that will seed the core of a "Why else is Tor slow" whitepaper over the coming months, as a sequel to the original. read more »

An increasing number of people are asking us about the recent paper coming out of Inria in France around Bittorrent and privacy attacks. This post tries to explain the attacks and what they imply.

There are three pieces to the attack (or three separate attacks that build on each other, if you prefer). read more »

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 »