Future areas for Tor research
arma at mit.edu
Thu Aug 21 19:31:57 UTC 2008
[I'm moving this thread to or-dev from personal mail so we can be more
transparent for the rest of the Tor researchers out there. -RD]
Hi Steven, others,
Here are some research directions that come to mind. We should expand
on this list, and also try to prioritize by a) which ones we can make
progress on, b) which ones matter most, and c) which ones I'm anticipating
funders want done when. I've mostly sorted the list below by 'b' and 'c'.
Eventually the list could go up on the website as research.wml.
By end of 2008:
- Paul's NRL project to evaluate path selection under various trust
distributions. The idea is to figure out safer/better ways to build
paths if we assume some users trust some relays more than others.
- Peter's proposal 141. How to trade off descriptor fetching overhead
with circuit-building overhead. Are there even better ways?
By end of 2009:
- Understand the risks from letting people relay traffic through your
Tor while you're also being a Tor client. Compare risks from being a
bridge relay to risks from being a 'full' relay. Come up with practical
ways to mitigate.
- Take Roger's incentive.pdf design, flesh it out further, and see if we
can find solutions to the long-term intersection attack that arises
from attackers being able to correlate "that relay is online everytime
this anonymous high-priority user does an action." (I need to clean up
incentive.pdf and send it to this list.)
By end of 2010:
- Better load balancing algorithms, path selection choices, etc.
Building on Mike Perry's work and Steven's PETS 2008 paper. Do we
do simulations? analysis? How to compare them? Are there cases when
we can switch to 2-hop paths, or the variable-hop paths?
- Evaluate the latency and clogging attacks that are coming out, figure
out if they actually work, and produce countermeasures.
- Tor network scalability, the easy version: use several parallel
networkstatus documents, have algorithms for clients to pick which to
use, for relays to get assigned to one, and make sure new designs like
Peter's proposal 141 will be compatible with this.
- There's a vulnerability right now where you can enumerate bridges by
running a non-guard Tor server and seeing who connects that isn't
a known relay. One solution is to use two layers of guards, meaning
bridge users use 4-hop paths. Is this the best option we've got? They
don't want to be slowed down like that.
- How many bridges do you need to know to maintain reachability? We
should measure the churn in our bridges. If there is lots of churn,
are there ways to keep bridge users more likely to stay connected?
- Related, more bridge address distribution strategies: Steven and I
were talking about a ``bridge loop'' design where bridge identities form
a ``loop'' at the bridgeDB , and if you know any bridge in the loop you
can learn all the others. This approach will allow Tor clients who know
a few bridges to be updated with new bridges as their old ones rotate,
without opening up the list to full enumeration.
More information about the tor-dev