mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 13:53:31 +01:00
Remove legacy files from main source distribution
The AUTHORS file was pretty outdated. Its contents moved onto the people page. Design paper and roadmaps moved to the projects directory in svn.
This commit is contained in:
Sebastian Hahn
parent
3a7e7f1be4
commit
f164a76f72
41
AUTHORS
41
AUTHORS
@ -1,41 +0,0 @@
|
||||
This file lists the authors for Tor,
|
||||
a free software project to provide anonymity on the Internet.
|
||||
|
||||
For more information about Tor, see https://www.torproject.org/.
|
||||
|
||||
If you got this file as a part of a larger bundle,
|
||||
there are probably other authors that you should be aware of.
|
||||
|
||||
Main authors:
|
||||
-------------
|
||||
|
||||
Roger Dingledine <arma@freehaven.net> overhauled all of the code, did
|
||||
a bunch of new design work, etc.
|
||||
|
||||
Nick Mathewson <nickm@freehaven.net> wrote lots of stuff too, in
|
||||
particular the router and descriptor parsing, and the crypto and tls
|
||||
wrappers.
|
||||
|
||||
Matej Pfajfar <badbytes@freehaven.net> wrote the first version of the code
|
||||
(called OR) in 2001-2002.
|
||||
|
||||
Contributors:
|
||||
-------------
|
||||
|
||||
John Bashinski <jbash@velvet.com> contributed the initial rpm spec file.
|
||||
|
||||
Christian Grothoff <grothoff@cs.purdue.edu> contributed better daemonizing
|
||||
behavior.
|
||||
|
||||
Steven Hazel <sah@thalassocracy.org> made 'make install' do the right
|
||||
thing.
|
||||
|
||||
Jason Holt <jason@lunkwill.org> contributed patches to the instructions
|
||||
and the man page.
|
||||
|
||||
Peter Palfrader <peter@palfrader.org> maintains everything that's
|
||||
debian-specific, and has written other useful features.
|
||||
|
||||
Aaron Turner <aturner@netscreen.com> contributed the first version of
|
||||
the tor.sh initscripts shell script.
|
||||
|
||||
@ -25,6 +25,10 @@ Changes in version 0.2.2.9-alpha - 2010-??-??
|
||||
- Generate our manpage and HTML documentation using Asciidoc. This
|
||||
should make it easier to maintain the documentation, and produce
|
||||
nicer HTML.
|
||||
- Removed some unnecessary files from the source distribution. The
|
||||
AUTHORS file had its content merged into the people page on the
|
||||
website. The roadmaps and design doc can now be found in the
|
||||
projects directory in svn.
|
||||
|
||||
o Removed features:
|
||||
- Stop shipping parts of the website and the design paper in the
|
||||
|
||||
@ -1,73 +0,0 @@
|
||||
#!/bin/sh
|
||||
# A script to turn Tor SOCKS4a in Privoxy on or off.
|
||||
|
||||
CONFFILE=/etc/privoxy/config # privoxy config file.
|
||||
TOR_REG="forward.*localhost:9050" # Regular expression to find Tor in privoxy
|
||||
PRIVOXY="/etc/init.d/privoxy restart" # command to reload privoxy config file.
|
||||
SED="/bin/sed" # sed command, of course.
|
||||
GREP="/bin/grep" # grep command.
|
||||
|
||||
usage () {
|
||||
echo "\
|
||||
privoxy-tor-toggle: Change Privoxy's configuration to use/not use Tor.
|
||||
Usage:
|
||||
privoxy.tor <-- Switch Tor on or off.
|
||||
privoxy.tor [on|off] <-- Set Tor on or off.
|
||||
privoxy.tor status <-- Display Tor's current status.
|
||||
privoxy.tor [-h|--help|-?] <-- Print usage.
|
||||
"
|
||||
}
|
||||
|
||||
# Find out the current status of tor. Set $tor_status
|
||||
get_status () {
|
||||
gret=`$GREP -l -e "^$TOR_REG" $CONFFILE`
|
||||
if [ x$gret = x ] ; then
|
||||
tor_status=off;
|
||||
else
|
||||
tor_status=on;
|
||||
fi
|
||||
return
|
||||
}
|
||||
|
||||
# Turn tor on/off according to $1
|
||||
set_tor () {
|
||||
tor_gate=$1
|
||||
get_status
|
||||
if [ $tor_status = $tor_gate ] ; then
|
||||
echo "Tor is already $1."
|
||||
return
|
||||
elif [ $tor_gate = flip ] ; then
|
||||
if [ $tor_status = on ] ; then
|
||||
tor_gate=off
|
||||
elif [ $tor_status = off ] ; then
|
||||
tor_gate=on
|
||||
fi
|
||||
fi
|
||||
echo "Turning Tor $tor_gate..."
|
||||
if [ $tor_gate = on ] ; then
|
||||
reg=s/^#\($TOR_REG\)/\\1/
|
||||
$SED -i.bak -r "$reg" $CONFFILE
|
||||
else
|
||||
reg=s/^\($TOR_REG\)/#\\1/
|
||||
$SED -i.bak -r "$reg" $CONFFILE
|
||||
fi
|
||||
$PRIVOXY
|
||||
return 0;
|
||||
}
|
||||
|
||||
if [ x$1 = x ] ; then
|
||||
set_tor flip
|
||||
elif [ $1 = on ] ; then
|
||||
set_tor on
|
||||
elif [ $1 = off ] ; then
|
||||
set_tor off
|
||||
elif [ $1 = status ] ; then
|
||||
get_status
|
||||
echo "Tor is $tor_status"
|
||||
elif [ $1 = --help ] || [ $1 = -h ] || [ $1 = "-?" ] ; then
|
||||
usage
|
||||
exit 0
|
||||
else
|
||||
echo "Unrecognized option: \"$1\""
|
||||
fi
|
||||
|
||||
@ -1,52 +0,0 @@
|
||||
Subject:
|
||||
Re: Anonymous/Nonymous Communication Coexisting?
|
||||
From:
|
||||
Kristian Köhntopp <kris@xn--khntopp-90a.de>
|
||||
Date:
|
||||
Fri, 10 Jun 2005 08:56:19 +0200
|
||||
To:
|
||||
or-talk@freehaven.net
|
||||
|
||||
On Wednesday 08 June 2005 04:20, yancm@sdf.lonestar.org wrote:
|
||||
|
||||
>> Is it possible to have a single application, such as a web
|
||||
>> browser or a p2p client behave normally with normal url's but
|
||||
>> use tor if the url is an xyz.onion address? Or is it
|
||||
>> everything or nothing?
|
||||
|
||||
|
||||
This is basically a question of using your proxy or not. You can
|
||||
control the behaviour of your browser in great detail writing a
|
||||
proxy.pac program in Javascript and setting that program as the
|
||||
proxy autoconfiguration URL in your browser.
|
||||
|
||||
An example:
|
||||
|
||||
kris@jordan01:~> cat /srv/www/htdocs/proxy.pac
|
||||
|
||||
function FindProxyForURL(url, host)
|
||||
{
|
||||
var proxy_yes = "PROXY jordan01.int.cinetic.de:3128";
|
||||
var proxy_no = "DIRECT";
|
||||
|
||||
// Redirect all accesses to mlan hosts to the mlan proxy
|
||||
if (dnsDomainIs(host, ".mlan.cinetic.de")) {
|
||||
return proxy_yes;
|
||||
}
|
||||
|
||||
// Everything else is direct
|
||||
return proxy_no;
|
||||
}
|
||||
|
||||
So here the program checks if the destination is a mlan-Host, and
|
||||
if so, uses the appropriate proxy on jordan for the access,
|
||||
while all other accesses are direct.
|
||||
|
||||
You could do a similar thing with .onion accesses with a trivial
|
||||
modification.
|
||||
|
||||
Docs:
|
||||
http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
|
||||
|
||||
Kristian
|
||||
|
||||
@ -1,41 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<metalink version="3.0" generator="Metalink Editor version 1.1.0" xmlns="http://www.metalinker.org/">
|
||||
<publisher>
|
||||
<name>The Tor Project</name>
|
||||
<url>https://www.torproject.org</url>
|
||||
</publisher>
|
||||
<license>
|
||||
<name>BSD</name>
|
||||
<url>http://opensource.org/licenses/bsd-license.php</url>
|
||||
</license>
|
||||
<identity>Tor</identity>
|
||||
<version>@VERSION@</version>
|
||||
<copyright>2007 The Tor Project, Inc.</copyright>
|
||||
<description>Anonymity Online</description>
|
||||
<files>
|
||||
<file name="tor-@VERSION@.tar.gz">
|
||||
<size>1251636</size>
|
||||
<language>en</language>
|
||||
<os>Source</os>
|
||||
<verification>
|
||||
<hash type="md5">ef8fc7f45d167875c337063d437c9832</hash>
|
||||
<hash type="sha1">01092fb75c407b5c1d7f33db069cf7641973d94d</hash>
|
||||
<hash type="sha256">fc0fb0c2891ae09854a69512c6b4988964f2eaf62ce80ed6644cb21f87f6056a</hash>
|
||||
<pieces type="sha1" length="262144">
|
||||
<hash piece="0">c778dd01e05734d57f769082545f9802386e42bb</hash>
|
||||
<hash piece="1">39b172ed8b9290884c7bd129db633a79e28d5ae9</hash>
|
||||
<hash piece="2">28d708e7489a1e9951e757443672535aedfa3abe</hash>
|
||||
<hash piece="3">a7623e07081819a37300de0511bbdda0bdc960bd</hash>
|
||||
<hash piece="4">f246021e55affe320a1f86eac5b049dd0caad828</hash>
|
||||
</pieces>
|
||||
</verification>
|
||||
<resources>
|
||||
<url type="http" location="at">http://tor.cypherpunks.at/dist/</url>
|
||||
<url type="http" location="ca">http://tor.depthstrike.com/dist/</url>
|
||||
<url type="http" location="ca">http://tor.hermetix.org/dist/</url>
|
||||
<url type="http" location="ch">http://tor.boinc.ch/dist/</url>
|
||||
<url type="http" location="cn">http://tor.anonymity.cn/dist/</url>
|
||||
</resources>
|
||||
</file>
|
||||
</files>
|
||||
</metalink>
|
||||
@ -1,357 +0,0 @@
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%deffont "standard" xfont "comic sans ms-medium-r"
|
||||
%%deffont "thick" xfont "arial black-medium-r"
|
||||
%%deffont "typewriter" xfont "courier new-bold-r"
|
||||
%%deffont "type2writer" xfont "arial narrow-bold-r"
|
||||
%%deffont "standard" tfont "standard.ttf", tmfont "kochi-mincho.ttf"
|
||||
%%deffont "thick" tfont "thick.ttf", tmfont "goth.ttf"
|
||||
%%deffont "typewriter" tfont "typewriter.ttf", tmfont "goth.ttf"
|
||||
%deffont "standard" xfont "helvetica-medium-r", tfont "arial.ttf", tmfont "times.ttf"
|
||||
%deffont "thick" xfont "helvetica-bold-r", tfont "arialbd.ttf", tmfont "hoso6.ttf"
|
||||
%deffont "italic" xfont "helvetica-italic-r", tfont "ariali.ttf", tmfont "hoso6.ttf"
|
||||
%deffont "typewriter" xfont "courier-medium-r", tfont "typewriter.ttf", tmfont "hoso6.ttf"
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%
|
||||
%% Default settings per each line numbers.
|
||||
%%
|
||||
%default 1 leftfill, size 8, fore "black", back "white", font "thick", hgap 1
|
||||
%default 2 size 8, vgap 10, prefix " ", ccolor "black"
|
||||
%default 3 size 6, bar "gray70", vgap 0
|
||||
%default 4 size 6, fore "black", vgap 0, prefix " ", font "standard"
|
||||
%%
|
||||
%%default 1 area 90 90, leftfill, size 9, fore "yellow", back "blue", font "thick"
|
||||
%%default 2 size 9, vgap 10, prefix " "
|
||||
%%default 3 size 7, bar "gray70", vgap 10
|
||||
%%default 4 size 7, vgap 30, prefix " ", font "standard"
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%
|
||||
%% Default settings that are applied to TAB-indented lines.
|
||||
%%
|
||||
%tab 1 size 5, vgap 40, prefix " ", icon arc "red" 50
|
||||
%tab 2 size 4, vgap 35, prefix " ", icon delta3 "blue" 40
|
||||
%tab 3 size 3, vgap 35, prefix " ", icon dia "DarkViolet" 40
|
||||
%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
%nodefault
|
||||
%center, size 9, font "thick", back "white", fore "black"
|
||||
|
||||
Tor:
|
||||
%size 8
|
||||
Next-generation Onion Routing
|
||||
|
||||
|
||||
%size 7
|
||||
Roger Dingledine
|
||||
Nick Mathewson
|
||||
Paul Syverson
|
||||
|
||||
The Free Haven Project
|
||||
%font "typewriter", fore "blue"
|
||||
http://freehaven.net/
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Low-latency anonymity system
|
||||
|
||||
%leftfill
|
||||
Deployed: 20 nodes, hundreds (?) of users
|
||||
|
||||
Many improvements on earlier design
|
||||
|
||||
Free software -- modified BSD license
|
||||
|
||||
Design is not covered by earlier onion routing
|
||||
patent
|
||||
|
||||
Uses SOCKS to interface with client apps
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
We have working code
|
||||
|
||||
(14 kloc of C)
|
||||
|
||||
and a design document,
|
||||
and a byte-level specification,
|
||||
and a Debian package (in Unstable)
|
||||
|
||||
Works on Linux, BSD, OSX, Cygwin, ...
|
||||
User-space, doesn't need kernel mods or root
|
||||
|
||||
%size 9
|
||||
http://freehaven.net/tor/
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%page
|
||||
%%
|
||||
%%Talk Overview
|
||||
%%
|
||||
%%A bit about Onion Routing
|
||||
%%
|
||||
%%Improvements we've made
|
||||
%%
|
||||
%%Some related work
|
||||
%%
|
||||
%%Ask me questions
|
||||
%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Anonymity: Who needs it?
|
||||
|
||||
Private citizens
|
||||
advocacy, counseling, whistleblowing, reporting, ...
|
||||
%size 6
|
||||
Higher-level protocols
|
||||
voting, e-cash, auctions
|
||||
%size 6
|
||||
Government applications
|
||||
research, law enforcement
|
||||
%size 6
|
||||
Business applications
|
||||
%size 5
|
||||
(hide relationships and volumes of communication)
|
||||
Who is visiting job sites?
|
||||
Which groups are talking to patent lawyers?
|
||||
Who are your suppliers and customers?
|
||||
Is the CEO talking to a buyout partner?
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Anonymity is a network effect
|
||||
|
||||
Systems need traffic (many low-sensitivity users) to attract the high-sensitivity users
|
||||
Most users do not value anonymity much
|
||||
Weak security (fast system) can mean more users
|
||||
which can mean
|
||||
%cont, font "italic"
|
||||
stronger
|
||||
%cont, font "standard"
|
||||
anonymity
|
||||
High-sensitivity agents have incentive to run nodes
|
||||
so they can be certain first node in their path is good
|
||||
to attract traffic for their messages
|
||||
There can be an optimal level of free-riding
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Onion Routing is...
|
||||
|
||||
An overlay network
|
||||
|
||||
Users build virtual circuits through the network
|
||||
|
||||
One layer of encryption at each hop
|
||||
|
||||
Fixed-size cells
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Tor's goals
|
||||
|
||||
Conservative design
|
||||
minimize new design work needed
|
||||
|
||||
%size 6
|
||||
Support testing of future research
|
||||
|
||||
Design for deployment; deploy for use
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Threat model -- what we aim for
|
||||
|
||||
Protect against somebody watching Alice
|
||||
|
||||
Protect against curious Bob
|
||||
|
||||
Protect against `some' curious nodes in the middle
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Differences / limitations
|
||||
|
||||
|
||||
We're TCP-only, not all IP (but we're user-space and very portable)
|
||||
|
||||
Not as strong as high-latency systems (Mixmaster, Mixminion)
|
||||
|
||||
Not peer-to-peer
|
||||
|
||||
No protocol normalization
|
||||
|
||||
Not unobservable (no steg, etc)
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Perfect forward secrecy
|
||||
|
||||
|
||||
Telescoping circuit
|
||||
|
||||
negotiates keys at each hop
|
||||
no more need for replay detection
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
No mixing, padding, traffic shaping (yet)
|
||||
|
||||
|
||||
Please show us they're worth the usability tradeoff
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%page
|
||||
%%
|
||||
%%Many TCP streams can share one circuit
|
||||
%%
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Many TCP streams share a circuit
|
||||
|
||||
Previous designs built a new circuit for each stream
|
||||
|
||||
lots of public key ops per request
|
||||
plus anonymity dangers from making so many circuits
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Leaky-pipe circuit topology
|
||||
|
||||
Alice can direct cells to any node in her circuit
|
||||
|
||||
So we can support long-range padding,
|
||||
have multiple streams exiting at different places in the circuit
|
||||
etc
|
||||
|
||||
%size 6
|
||||
Unclear whether this is dangerous or useful
|
||||
|
||||
More research needed
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Congestion control
|
||||
|
||||
|
||||
Simple rate limiting
|
||||
|
||||
Plus have to keep internal nodes from overflowing
|
||||
|
||||
(Can't use global state or inter-node control)
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Directory servers
|
||||
|
||||
To solve the `introduction' problem
|
||||
|
||||
Approve new servers
|
||||
|
||||
Tell clients who's up right now
|
||||
|
||||
plus their keys, location, etc
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Variable exit policies
|
||||
|
||||
|
||||
Each server allows different outgoing connections
|
||||
|
||||
E.g. no servers allow outgoing mail currently
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
End-to-end integrity checking
|
||||
|
||||
|
||||
In previous onion routing, an insider could change
|
||||
the text being transmitted:
|
||||
|
||||
"dir" => "rm *"
|
||||
|
||||
Even an external adversary could do this!
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Rendezvous points
|
||||
|
||||
allow hidden services
|
||||
|
||||
don't need (brittle) reply onions
|
||||
|
||||
Access-controlled: Bob can control who he talks to
|
||||
Robust: Bob's service is available even when some Tor nodes go down
|
||||
Smear-resistant: Evil service can't frame a rendezvous router
|
||||
Application-transparent: Don't need to modify Bob's apache
|
||||
|
||||
%size 6
|
||||
(Not implemented yet)
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
How do we compare security?
|
||||
|
||||
Assume adversary owns c of n nodes
|
||||
can choose which
|
||||
%size 6
|
||||
What's the chance for a random Alice and Bob that he wins?
|
||||
|
||||
Freedom, Tor: (c/n)^2
|
||||
Peekabooty, six-four, etc: c/n
|
||||
Jap (if no padding): 1 if c>1
|
||||
Anonymizer: 1 if c>0
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Future work
|
||||
|
||||
Threshold directory agreement
|
||||
|
||||
Scalability: Morphmix/p2p extensions?
|
||||
Restricted-route (non-clique topology)
|
||||
|
||||
Non-TCP transport
|
||||
|
||||
Implement rendezvous points
|
||||
|
||||
Make it work better
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
We have working code
|
||||
|
||||
Plus a design document,
|
||||
and a byte-level specification
|
||||
and a Debian package (in Unstable)
|
||||
|
||||
%size 9
|
||||
http://freehaven.net/tor/
|
||||
|
||||
%size 6
|
||||
Privacy Enhancing Technologies workshop
|
||||
|
||||
%size 9
|
||||
http://petworkshop.org/
|
||||
|
||||
@ -1,21 +0,0 @@
|
||||
cell-struct.eps: cell-struct.fig
|
||||
fig2dev -L eps $< $@
|
||||
interaction.eps: interaction.fig
|
||||
fig2dev -L eps $< $@
|
||||
cell-struct.pdf: cell-struct.fig
|
||||
fig2dev -L pdf $< $@
|
||||
interaction.pdf: interaction.fig
|
||||
fig2dev -L pdf $< $@
|
||||
|
||||
tor-design.ps: cell-struct.eps interaction.eps tor-design.bib tor-design.tex usenix.sty latex8.bst
|
||||
latex tor-design.tex
|
||||
bibtex tor-design
|
||||
latex tor-design.tex
|
||||
latex tor-design.tex
|
||||
dvips -o $@ tor-design.dvi
|
||||
|
||||
tor-design.pdf: cell-struct.pdf interaction.pdf tor-design.bib tor-design.tex usenix.sty latex8.bst
|
||||
pdflatex tor-design.tex
|
||||
bibtex tor-design
|
||||
pdflatex tor-design.tex
|
||||
pdflatex tor-design.tex
|
||||
File diff suppressed because it is too large
Load Diff
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@ -1,189 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-2.0
|
||||
%%Title: cell-struct.fig
|
||||
%%Creator: fig2dev Version 3.2 Patchlevel 4
|
||||
%%CreationDate: Mon May 17 00:04:58 2004
|
||||
%%For: root@localhost.localdomain (root)
|
||||
%%BoundingBox: 0 0 254 73
|
||||
%%Magnification: 1.0000
|
||||
%%EndComments
|
||||
/$F2psDict 200 dict def
|
||||
$F2psDict begin
|
||||
$F2psDict /mtrx matrix put
|
||||
/col-1 {0 setgray} bind def
|
||||
/col0 {0.000 0.000 0.000 srgb} bind def
|
||||
/col1 {0.000 0.000 1.000 srgb} bind def
|
||||
/col2 {0.000 1.000 0.000 srgb} bind def
|
||||
/col3 {0.000 1.000 1.000 srgb} bind def
|
||||
/col4 {1.000 0.000 0.000 srgb} bind def
|
||||
/col5 {1.000 0.000 1.000 srgb} bind def
|
||||
/col6 {1.000 1.000 0.000 srgb} bind def
|
||||
/col7 {1.000 1.000 1.000 srgb} bind def
|
||||
/col8 {0.000 0.000 0.560 srgb} bind def
|
||||
/col9 {0.000 0.000 0.690 srgb} bind def
|
||||
/col10 {0.000 0.000 0.820 srgb} bind def
|
||||
/col11 {0.530 0.810 1.000 srgb} bind def
|
||||
/col12 {0.000 0.560 0.000 srgb} bind def
|
||||
/col13 {0.000 0.690 0.000 srgb} bind def
|
||||
/col14 {0.000 0.820 0.000 srgb} bind def
|
||||
/col15 {0.000 0.560 0.560 srgb} bind def
|
||||
/col16 {0.000 0.690 0.690 srgb} bind def
|
||||
/col17 {0.000 0.820 0.820 srgb} bind def
|
||||
/col18 {0.560 0.000 0.000 srgb} bind def
|
||||
/col19 {0.690 0.000 0.000 srgb} bind def
|
||||
/col20 {0.820 0.000 0.000 srgb} bind def
|
||||
/col21 {0.560 0.000 0.560 srgb} bind def
|
||||
/col22 {0.690 0.000 0.690 srgb} bind def
|
||||
/col23 {0.820 0.000 0.820 srgb} bind def
|
||||
/col24 {0.500 0.190 0.000 srgb} bind def
|
||||
/col25 {0.630 0.250 0.000 srgb} bind def
|
||||
/col26 {0.750 0.380 0.000 srgb} bind def
|
||||
/col27 {1.000 0.500 0.500 srgb} bind def
|
||||
/col28 {1.000 0.630 0.630 srgb} bind def
|
||||
/col29 {1.000 0.750 0.750 srgb} bind def
|
||||
/col30 {1.000 0.880 0.880 srgb} bind def
|
||||
/col31 {1.000 0.840 0.000 srgb} bind def
|
||||
|
||||
end
|
||||
save
|
||||
newpath 0 73 moveto 0 0 lineto 254 0 lineto 254 73 lineto closepath clip newpath
|
||||
-35.3 77.2 translate
|
||||
1 -1 scale
|
||||
|
||||
/cp {closepath} bind def
|
||||
/ef {eofill} bind def
|
||||
/gr {grestore} bind def
|
||||
/gs {gsave} bind def
|
||||
/sa {save} bind def
|
||||
/rs {restore} bind def
|
||||
/l {lineto} bind def
|
||||
/m {moveto} bind def
|
||||
/rm {rmoveto} bind def
|
||||
/n {newpath} bind def
|
||||
/s {stroke} bind def
|
||||
/sh {show} bind def
|
||||
/slc {setlinecap} bind def
|
||||
/slj {setlinejoin} bind def
|
||||
/slw {setlinewidth} bind def
|
||||
/srgb {setrgbcolor} bind def
|
||||
/rot {rotate} bind def
|
||||
/sc {scale} bind def
|
||||
/sd {setdash} bind def
|
||||
/ff {findfont} bind def
|
||||
/sf {setfont} bind def
|
||||
/scf {scalefont} bind def
|
||||
/sw {stringwidth} bind def
|
||||
/tr {translate} bind def
|
||||
/tnt {dup dup currentrgbcolor
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
|
||||
bind def
|
||||
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
|
||||
4 -2 roll mul srgb} bind def
|
||||
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
|
||||
/$F2psEnd {$F2psEnteredState restore end} def
|
||||
|
||||
$F2psBegin
|
||||
10 setmiterlimit
|
||||
0 slj 0 slc
|
||||
0.06000 0.06000 sc
|
||||
%
|
||||
% Fig objects follow
|
||||
%
|
||||
%
|
||||
% here starts figure with depth 50
|
||||
% Polyline
|
||||
7.500 slw
|
||||
n 1200 975 m
|
||||
1200 1275 l gs col0 s gr
|
||||
% Polyline
|
||||
n 1725 975 m
|
||||
1725 1275 l gs col0 s gr
|
||||
% Polyline
|
||||
n 600 975 m 4800 975 l 4800 1275 l 600 1275 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 1200 300 m
|
||||
1200 600 l gs col0 s gr
|
||||
% Polyline
|
||||
n 1725 300 m
|
||||
1725 600 l gs col0 s gr
|
||||
% Polyline
|
||||
n 600 300 m 4800 300 l 4800 600 l 600 600 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 2550 975 m
|
||||
2550 1275 l gs col0 s gr
|
||||
% Polyline
|
||||
n 3150 975 m
|
||||
3150 1275 l gs col0 s gr
|
||||
% Polyline
|
||||
n 3450 975 m
|
||||
3450 1275 l gs col0 s gr
|
||||
% Polyline
|
||||
n 3900 975 m
|
||||
3900 1275 l gs col0 s gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
675 1200 m
|
||||
gs 1 -1 sc (CircID) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
900 900 m
|
||||
gs 1 -1 sc (2) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
1275 1200 m
|
||||
gs 1 -1 sc (Relay) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
1800 1200 m
|
||||
gs 1 -1 sc (StreamID) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
2625 1200 m
|
||||
gs 1 -1 sc (Digest) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
3150 1200 m
|
||||
gs 1 -1 sc (Len) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
4200 1200 m
|
||||
gs 1 -1 sc (DATA) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
675 525 m
|
||||
gs 1 -1 sc (CircID) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
1275 525 m
|
||||
gs 1 -1 sc (CMD) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
900 225 m
|
||||
gs 1 -1 sc (2) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
1425 225 m
|
||||
gs 1 -1 sc (1) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
3225 525 m
|
||||
gs 1 -1 sc (DATA) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
3225 900 m
|
||||
gs 1 -1 sc (2) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
3450 1200 m
|
||||
gs 1 -1 sc (CMD) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
3600 900 m
|
||||
gs 1 -1 sc (1) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
3300 225 m
|
||||
gs 1 -1 sc (509 bytes) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
1425 900 m
|
||||
gs 1 -1 sc (1) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
2100 900 m
|
||||
gs 1 -1 sc (2) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
2850 900 m
|
||||
gs 1 -1 sc (6) col0 sh gr
|
||||
/Times-Roman ff 180.00 scf sf
|
||||
4350 900 m
|
||||
gs 1 -1 sc (498) col0 sh gr
|
||||
% here ends figure;
|
||||
$F2psEnd
|
||||
rs
|
||||
showpage
|
||||
@ -1,49 +0,0 @@
|
||||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
1200 975 1200 1275
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
1725 975 1725 1275
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
600 975 4800 975 4800 1275 600 1275 600 975
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
1200 300 1200 600
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
1725 300 1725 600
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
600 300 4800 300 4800 600 600 600 600 300
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
2550 975 2550 1275
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
3150 975 3150 1275
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
3450 975 3450 1275
|
||||
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
|
||||
3900 975 3900 1275
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 510 675 1200 CircID\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 900 900 2\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 180 435 1275 1200 Relay\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 735 1800 1200 StreamID\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 180 510 2625 1200 Digest\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 285 3150 1200 Len\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 510 4200 1200 DATA\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 510 675 525 CircID\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 420 1275 525 CMD\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 900 225 2\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 1425 225 1\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 510 3225 525 DATA\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 3225 900 2\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 420 3450 1200 CMD\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 3600 900 1\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 180 735 3300 225 509 bytes\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 1425 900 1\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 2100 900 2\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 90 2850 900 6\001
|
||||
4 0 0 50 -1 0 12 0.0000 4 135 270 4350 900 498\001
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 5.9 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,168 +0,0 @@
|
||||
%!PS-Adobe-3.0 EPSF-3.0
|
||||
%%BoundingBox: 0 0 594 282
|
||||
%
|
||||
% created by bmeps 1.1.0 (SCCS=1.73)
|
||||
%
|
||||
/pstr
|
||||
1782 string
|
||||
def
|
||||
/inputf
|
||||
currentfile
|
||||
/ASCII85Decode filter
|
||||
/FlateDecode filter
|
||||
/RunLengthDecode filter
|
||||
def
|
||||
gsave
|
||||
0 282 translate
|
||||
594 282 scale
|
||||
594 282 8 [594 0 0 -282 0 0]
|
||||
{ inputf pstr readstring pop }
|
||||
false
|
||||
3
|
||||
colorimage
|
||||
GhVOjDi>]<FajlqSJie3"Aig\TXkI[MM+kbD;&*L=t/GMV-hs)5>n9_WC$R38uPNS
|
||||
:\/!h(->g0&o'd+8jO"#,u#\]-qJ1e";8Kq`509MM1b+?CGo=.n_,W;mpme-e![aj
|
||||
B("Hbs6'BNh5d)*o60!7giMmDpRL,(pWU;Y7i/+RPG?h0oNsh*1qc+:\e*?imYf?h
|
||||
re5U2P]Er&[l@U7MGMBC<a&dq32GfDGWpC0c6`qhbLO?+4%u@8Z/Vdnq"treSqVDa
|
||||
\U#EJUY%e5Ph#d,:B[]`lVll3`Q9BVa#HgAoB(Bt*4*aZo7("N(W4Q'r4i65/`js/
|
||||
061>D:!%,B]fqbFk0:H<3\DZWUJuk]n`SCZd8H)<CDVC+qoL]1fjpXph0Q![-O?Oq
|
||||
n2%`,NU$PO:5qJ*XDRK*P<t":(jqY4cZFDZM5+?Fc#ZM$-E"'\bBrOCFfhh@jSBjM
|
||||
f:%bZ^h\g@?;f;.19A;qa6-IE5bGYGqlO2:J$;Gj6N""i>pE_P!2XOs^VlZn5=9gq
|
||||
SE9TkJS0@]8s0%XFBHtSSdhZ7mZ"DR\ETm=>(Yd+lps3F+2>#X8RI>kQHh'^kE]G/
|
||||
a-5/<G.p/S\TAfTXlOXK5G)$?o9\G+,^,uSYE+&$4BjjYqN7SgY7t'?'`N!Q^[T)g
|
||||
/]C$ZS1Y)G<UX2C0U&MVY3<'G=.rD^)@r<3<ggnVGFjRkYJXjJq:Y)V,*4CW$M@nY
|
||||
NL*V(Qd.j5TJKEVZ`/?XB$ZD&"QGh-OD_k&OP;`"JT]DO9<1iMLL>?j@AaZ!H*6[I
|
||||
W$g(]g^4*1cPI-WK.qdDQoH*_jR`3(kp3I@FTFUH.,QhO4Pd\`)8Xm2MW:P73+qe\
|
||||
l(RWFgm5I>8e&2oY10M02D"Bgl>$6gA8)eEL"!-DKD@0"<oXfT1(9!LgNJujgbDB8
|
||||
lc6]'n#IO/CtkdTgkJ%iQsJ=e777##4S;<q4[KHA&kX:>#m>K/.3VuT5IN3;!3&q6
|
||||
9.PR*SN*mGlIajjqQ8^eneFI#aI<?j/=R07$/0'ElO9To55d+AlhXG%89U!ZlcAtO
|
||||
S^+cHqB;RVg</;?YrJof2t`YLp8K6JL$7'B=mp27ff([#\Wm,[0\m!:a1-7_X">h)
|
||||
%BW3%i[Ym_R]4`UTdSXfJ3)6W4TfuNFO]o*I_.]iijHIdht#$U)$0f3eA.uk[0r'b
|
||||
<A"ZaLu8ql1t,nPYn04AUs2kUP*SgT5[l%shgKb2=^:R=o.U-77ntMWVsgE(;dCQ4
|
||||
'qE2$X</F>#Aj=';Rad""$Q7lM$q$i%F(T&OXpc=%`R%j9CL[no72iYSO_=(6@q]E
|
||||
J.C(`=q/trfLN`&@=,6Ocg0I1TGQL%CC&iZ8+6Rqj*#<^Q;eI=.Y2TO+Q_EAcn?Wa
|
||||
D`X6FY=JerlZAa_r)+9m)OZ)5&nU[lbp5nB+FEJ'*7hr1Vt+RqGW-&sK7DXdY\rA.
|
||||
'@"E3Fso6;ktS/,81ZP$Ch'):.7*M!9j[YpCV#.'e9%,qS"bg%l<IZ1%_jaOckeR2
|
||||
F!CA@j9?J!%DX7aLW-KB&G]IqK+S7pmr+T0\AHnIN=TM_haXFkc8VpA*cjH6oRT1R
|
||||
W1!q;(eP6bqGjNuGV]RF$erJQ2pbF?Q(;q*7rI^=CRR[[m@s#RH)V]9i8ALDoJrab
|
||||
U(6UuF1M;D7$&]1@qm4$=.4CHWM4($&XXX%_1PuaeN.338X0\">3;Y@#Fe)[1)cT^
|
||||
`W@OtV$9,#QRWFc7:7PH<%8!uAtNHE*VKHXBJ>-B?pFj<+>3,,V&^Q/bcCQL_^]X4
|
||||
bg"PN1V4F<Qeta">h%#hd1CBhK/Y<d"f0UX.ttb9Ot@,t\E<1SL3^WGX4.65Z+/%6
|
||||
>Rs%7SBu)&b[oN_ERW$FaNtClNe,n\X+=I)**h430XhM!i&c6kAcE#+[h7e2>D>?0
|
||||
:uV.oZ`qRK\fpLsKWeTG4SfYLl+;^NC8O9Z^=5h>Q1P[)*+(FKTT)tKb&s^-s7``i
|
||||
c%(Q68^3oO+_G6h/*VT(D&iLWh^,rI5G]u>F2HJY`_6:tF?Yp-q"-$shiEhNke'kW
|
||||
?15Lfc3(-;jGpX*W7<ihq>/'WjnVs:NM6oShm"ppNbghEDn2Oh6Mt+Xq&1!Np>/HE
|
||||
a(AjV,f?ssgoh)WR@=u%!BsirW&BkYpp=-Q'udI76+k%AbLNn65G6ZLjjlWDnjA@R
|
||||
#D_*9#PS'?X9(kKN)=MlV$]sthLR%c=V_H=H'1s\:"BorK7OP%g>'r;Zp?h\ecr6+
|
||||
KI(MQe&(6N]\Y(0cBC/q-G&`k-V#S!@2;3cFXT-:klfY]6;&!-[]gF(4Z-WZ0bt"M
|
||||
>!pLt&ksVXea3>AW*0WX`WL?;DD5D9=<+rK)=5e#C8&qCf8Xbrk(;fL>lFk.*84PT
|
||||
Pc?uRaumCeIj/2&fEH,Z^'mU".9EH[X_,,FaK$GM(mQMO'"lZF`OflCE5K;^M+3pJ
|
||||
TMKOa+ST^jX;!s>c``QXaL\O'kFdTYfS=n-]:T+-4bN[0RgNB$\GoD"P^$WT*;%h]
|
||||
a&ih_/Z/le''^/Krf>WE+ZMnnm"(k)7DVB.8L-uOfPEb)f,Rc0>KligeqWmJ'[Rq+
|
||||
#8kT>ZqA\8e5`d]+n6/\QP#Q!R:ZOcnV:ddH4A8R6Q4fN*Ms-2i%+Jj3sTq#crqmi
|
||||
RD(mbp`cS0J^/m8H=+2Ola/7],0-c)E)XnZd3sd91#00]bu09lpk6t2r^[HGTL0:G
|
||||
Ta=p`4_c^is3:9]ac?s6k<9-:dM302pL3'#"'TMb%LhL)-gGp`?V:/T\9RK$P4qW=
|
||||
T.M2s_>mEl=M[TMaJm0<n?jX%m>(N1Unl\'lA!?J7@\#]Bsg?7;&b;cYhlT<:QtJc
|
||||
Q:>a-,<\\*?hq%f[7(2\>1bW9>B2e!1g!_G[u,K;F75r4,c?gtaL7\L2Q`t>/!/`\
|
||||
qp4jE9$Slnh=1\33IF]rI<YAjMm=tm@pt$d:7^j-[=>(Mmmj30032FeK0R#7IuHDT
|
||||
W31!/?O_U>:WUXK[S+\Y%5qe)%-%NQ?ubB`Kb'42F_(B]Tp5DfXO\iNLXRe/EP#1r
|
||||
QOiu)T=%iK+H'dl*,]1-E!S)tFOQac@e^.YWJZsh_qWS<'VC-!DbG<^G/.33fu/lJ
|
||||
5i\eM/]De)!Dpg@6#Dn%Hk1=WYJh[6T(:kXhY)9pf=[-)0!AWII(:PD)j9]sp=(DQ
|
||||
GrF=X6aHC`2`?l)g@5e^"8t"=j>YVrfm[5H>Ab5iY?*qqmaXG)='VfSUX`)B\(;!9
|
||||
$)?lDAdn(AYuN5EdV\LW7G3oXM-P1c9g&;7qmh&i>Hh/Z>Li(%[8clI0dEpQ;3IQY
|
||||
GPk*_Md2IK"&Fa;iMd]haBnt*]aqRbS,#8s^$AA(=DD#f$JBQ5?KPuGYmCij_Z&[o
|
||||
$ebL%T/>93"`*K<;+%dJ_'hu[=/nc.UIohOEsXt_*8>_Fi./Vf#i1QmIFLnd5qiq[
|
||||
#YHVTJkBBa`Jn]"^PfU4`b*[dq_c&U<F83o;V#-WN+b-][EaehDA2@(I=1(2.IpX>
|
||||
`+S0GR2Ye1=mWTAc>DC"Pg+[8;33K<F%rV.,"YLA]L8hOEp^!&5&4?n602DW:45oP
|
||||
Vr!!Y.HK[cRW%A58]dU5<ff_epn_$fs3kZuBf0C=Y0o58Mt@P5D*qjU,dP=Y1$<kL
|
||||
*<_T!"J9Z(.ZE2mG!dsI'u\Q4.'2j2"o'i(4@T^CWeVDte#=0jAfS!5B+hH_cl?.L
|
||||
A3Eb:]@Xr.n$$>lZfH[9,Ui7=q@)WJMhZ2AAsVoS9eUsl+2B.Fc_&>ZT"`4+dH*X"
|
||||
!\gu-rk(WQ59f,^Cpb,M\rh,Q1GtdaY_)0']Ig<a`P<bY0r'VDs"]aR,lMjK`VV54
|
||||
g&,=.G^^M`k_`WdmtZ;$dM?jB5)N1l]=35oe^.V8RKAZ.NeTC"BS`s-=AWk3@h('O
|
||||
?>ei"NO@L^nSW54&'ND\_h&dP2YMDpa/nuQfHR[h`n4K1-%AeG`&:&*S"`IB[V:U8
|
||||
@Hcf(IoHWI5]8SaK0I`)'oI[hoZ^%,cmC!NZeJ)jHNfo^)uJ"#TrAM#fn?V2T?&52
|
||||
[!#:WS6f%44N+.-r38gZ)s!LPcqCQBZ8%(,9q.I\9N*)281j0&.(2a7gKqF@n101$
|
||||
O>Ud.5U6;eNnP-U)P[VCQ/Y+d7^/d2'N"Lr%)ut]e"akJ6[jKb+cOo_M+edEp%mDo
|
||||
>EGpE4&?$'L*qBjc8L3u1UKGe2l>=Z]%nrY[GXRp;'.FTTD2`-N;YZYonrD_c[i1>
|
||||
R6YfR#T>DODc/Argc&WeSF-c)g.W'^b&kEg)`;iOgX+Gr9fq(Y]RktkJTiLeo!2tN
|
||||
hgI<GS;la?+Lre.1U55lTnXSU=N!X;]9^2/I(R$_Qj,20=VG0PRJL[^4u-8k^l$Pr
|
||||
%F]g+mr&u:?"DdX*@3[rrQN?X7AjR8c2A+L"j+S;?n((;=OVf&3!ZCEYsm'Y`jI!`
|
||||
@#q`:&/_^#Q+X2[kuHh]FCKpESJdp#=IORAG],fVCnKM6_;@]=g9ui'J<@:BCHEXM
|
||||
`/n]fUZoikC`^!$#919lc\87e$pNH*+&6S6(\'2\AS5mJ7p+itN0Pm@i$3#>M7gN'
|
||||
,Z4#UAEMInh;cT00<+g8aH>j6CRc\1E[M=OhBq$nl-hAZL9GrTfZrfCf3t-$Z'^b!
|
||||
N$u.t(5$J5aBX-j"i:Mr^7/ASRst,m_L%?1G$,mukB#e8G(3?ZL5VbG*ZVl9Msb4]
|
||||
`SnPXjHnliZ)0=TDX&IX$[Y5QnEY*hQ<F?T>bg<>RY&WC!!m#F0tc!(aa<mph?!A#
|
||||
n)aH*"4t]P"Z<)mh=&b=c^Q"a'u#`jeX#)-MGj1q>!,_?d%?1(N3NZe,OHo%oFfB\
|
||||
MMWYuQ\A8'mQGUCS"f2S[J7kI9$Ul7AYItiZVHaf[7-$rU-t:o^t+jfIf63"cJC7b
|
||||
4LnS56phbs;DYb1gAu)ZN#f^=6./Ht8pT)]Y;PXLE%bW?6q!_DmS&hE#d/%P;J2J+
|
||||
s3d]t>_,i*35GqB"!JjZO^Dg7JjsWga>A]&k0.PXjk$BXo,TuFbt^?>*[pGJg*08$
|
||||
ppf_6a1/h4>2F[>I'jDE_1N$?i_!Bk4lOHnAe:fV/U3Aa%6/gXaKqTQ'oHen\:0W@
|
||||
_i^n<PuWqFHL+[<Mo])Tjo02af5M/P^M`db9>/*V:]WlQ#pr$Par%"/!@R^[8&N`+
|
||||
o"t,GKG3H.\)gDTnG"GacVY06Ll7jC1o,4aS>O#PgFsNsO#^.0P[Sg:RV(skjjL\O
|
||||
V?rj!3rlYR,GW'%Md->._2@hE3mH)r^:1OlT-d&bBnh:X*lS<=S=,5dN2c(T[/D;q
|
||||
#tE-\b_r_O>=>::F<n?'-/)3%2n"Xr^Hqot4ANiFK?,%4*+VT&6Qor7,>h/KE)jX!
|
||||
!'>&Z<SAS.pg*jiiWK1'eq6tLZ5qZC,m1EKYDYL9'1DIe[WFFhUJ<9N:G]O=QZ]lH
|
||||
m,5E)Eku<Q&B?q$I9hU/W4>^mqp!-+;o/R"Ocb3#1\'3EDQq#,Lsqb),T?rT.^-+n
|
||||
NEGl(!ZUUGA^<fiKZKc`r(JqhB`l;eO*=#WPk98ZT;VV<2*%.<64adS0+r0.m&)W@
|
||||
=:uJjC',j;Ark;:]XZYB('G3U+A09iWg=X8",l50ijF]^om94g9%b0aEu+B%<F+&u
|
||||
'QN:<-8(Xi6]o[d9T`-URcD6s\"8C&S'[RB`Tja^`g%PHPq6)`(JP;K;NehVBFJ^M
|
||||
+JPjLpn5cQ]BYq4luTcg*KSV66$p=!g%!;YGnIld(:c.9=s&lb]2_=j`:)2bM'DQ9
|
||||
I,^\+,(j0@%Q#A>f7<%E!B4eL6f2XA!?r2+;8Og-/Gd5t:<eMT)E$VU!JLuVm*%">
|
||||
9nJbA_l4TaKA[>BJODXt#\R;_B-!qZGA4$DXn\hQ9%tt7F[q&OIAJ*/+F$PTpN8ge
|
||||
ehJr_Ns'=n#UcQJ9@`_K-[eP7K+p$R>$"uCqm>[Gb0'.ASQ%l]`R+?#1J^q^_]ki7
|
||||
H"W/LDqImO9'=au>Jmc8'hAe!(u\dnD?&*^Xc>V/8g9CqGE(/&V]j/J4)^u2)L(n=
|
||||
B^DY[Qq2OlNbUbKSZU3NBi@Oe,n'r=pY?8Dmoc0sNf4T_jp12igW[OU%=MJ:P0ESq
|
||||
-.H6KOW+Dk%,grA#GnG%3osd^\*&H^Ir;DuqZ4)4!_/'M5gPfhEtJnE7[B3pUlCVL
|
||||
kTPk2UX_VY3G"@LN(TPh_&IrfdQS*-bOEMY)1=P+](St7[s^P]cZE@9BiKIA8B[,0
|
||||
8HX:iE#U,*4@4M$G;*fI?sY7qrAKG<LdXYbk;HjlJe&$F_h+<!';$0.d.h7imUM"I
|
||||
'K!S8IMn/]?IIns\1biuVrjE/P9'(P=^A#J@Zig0Le(=(2!j]0aPP34K<4I8QEf)o
|
||||
RhW'<[D+\Q5r<ih-YU@6)44qViie5RGL;*?M_$o%;C5SCJ,3<I\OOVIi68m_(HI.`
|
||||
[LCs53'gRfr6P;)g2l>omojQi]:2EI:ZoAl]A'gk_YnHFVt-9DOM/9n*XcPP9<*UZ
|
||||
Q;_=ZjmSEg[RVggGBB3+A@35u7gE8tWjGJ?3,'WG&ro.eb*R:F5\MDe@+i$3,fh!i
|
||||
:"6?O7_.]FCY'p4!8><</oJVZQ*]El>?2V2RJf!n5HRusha^CDCAVU^6h0"rEYT0X
|
||||
&VQ<94-0Bps,QQC@C7t;5BC#@?ekB%8s:c"&&uilDNk%>%2OJ2-_L]h*[9Ul"0<5n
|
||||
pa?P@^62jXoboK0K9G>&KbkW4P^^Hkh?rl29aBVm*_"5"U8cd=0QPrQeq;%m?c6NR
|
||||
&0po_:>/n[Q=#/S&iZ(?bP1aKqn-n-%5DNRGkRf>JKSa(*'_e*MBAR.,NGBmL=p6P
|
||||
l/1=&GASg*(+(g)R*)I\nuUq317rQp6CEF>M]*t-kQ9#OHEO5N:YC\TNXiV:RZSPJ
|
||||
@BB^<$&u<6E7>?\b]:X+]Cd.3Y'oWh-.e:4mLE97+9PV6o4o8hfuO[0=I)H*dt5aQ
|
||||
*iV%!8K0]J1g+TZ+f"(hS%^e@7BLdCm(KWso*U#6q+f8uDb'I+25,,mpIZ6\8r^/Q
|
||||
]/+E+q'&['C?#bm!(P!:7V*D8$XbfA;(ON;%mYEo[9;Wm4X%8NTWr&./*!%^P\bYT
|
||||
5m&)E*VUK%2osk3p.:$NduA%2It0[INLn8GeBeR<-p9jl&i=IPTQAhBPi8*_Fb3L9
|
||||
2sA1l,@_;MV1H%O#Ea^8J9M4++kI5,.ln+bR)1Eo\G#'8ok.Q)+c#R&R>,a[:?iYh
|
||||
;e+9$#0dJOWTYUj-kK/F42b!3mfEKE:K*Qh[-%h#7sm84)TWKElE-C]F"WFPNCOD:
|
||||
\R8R&qZ)V"&N%L%DO01ZOLBgGl/Q0+]#[/j+5Pd@.3=>4!$[sOh@TS=8_iX:]g;A(
|
||||
0(/Vq+Z?9KrObJ1mZR\^d(M8FM^(1!ERiDG#)Xrs9Rhi$NLM%"F8P=ZBr/I]5L*T$
|
||||
grD+i+.3U@+I@2n96l3(_<';d;h2-V`],*8^jY-ikAi4iN/%f_:T'O0I(W5=qV/?&
|
||||
2`%"KJB.a8:W(DW!@%CIOoKZ^<M#@c1H:Rgifd>'cukK(%fue=g^!6LpG1LlkQrFD
|
||||
29:2U(0<J@hSmSHL<E!CV`EeMqqrhoDLe>[I_(-'1RlXj[iKRQGcW&KZBN/[9h4?I
|
||||
_sTm<VF[G(8=9n`YRc(RaiJt+.fdtFaEBH,=lHJ\Y`rqAJ>uY6JCT1Y0.:$:!B<JN
|
||||
"h>lB!#n7VOjP5oG_.#TJG.3-J$uuFWB$73DN3%QifIP?H<\9oJ^G5h<@0js.KfEr
|
||||
qq]<k>t-TAn'R&3Z"Psrjs98P.s`R')SjoZ!G:C$=S^B[*A5DVa1ZX_,L\fB;-@_i
|
||||
H8)\YbUcn5ZgUTX#8M[*!8:.j5X9nt^jY.Tfl$?3A-7q<K%HU6f.<c'\;d]F;d;)g
|
||||
4uQVl0Q:V/AUA!q>&qYlZ;#%c:F;R%^c*<Qlat7K81SX$\.:"BLf`+\QU*mi!G)M#
|
||||
*DlI48(ka^frd*$V^%Vd2b`HTp0f':cEac._="QSO4%Vsfhokd!Hn_#*FO'sDXWr8
|
||||
QfIgf6@^k2+1MitD$RoEn;:73f`>XhPT<SD5hQ0R"RZBdJbsu'"3M*%4.tqjZ3/8C
|
||||
#A#:Q<V^0G)B/#kj(u"6N-?u4_0?4F*K7K-`qu2O0k)#hn>?U,Se[mJ@)dg:%q[qk
|
||||
nR0AWJ\fh1C1,.bTdB_V@E"Gi'?B@u\q3n'b9g:^mN]NKTfq%1f0gsD(YI&e.5eAk
|
||||
bZ1_YpSR[qEda(`JVl<6HVNSH*)q8XY)fltV[^,W<#9<*$U52(DIF"G"q0tmEG<f:
|
||||
ig8Wo,^,uSYE*V+h2RErqV@>.l/]U\'8NSL0sn!B,Om8;2>(>[mI.dOpT91Y+'8?+
|
||||
X6rniI!ZNu9oAmFMu@D`s'*b@5E4\pa`fXG6CsJY[&9ImXYfd;>b*<-Mp4%aL#:J>
|
||||
2/+3Pn8+>hV%0mNr1jKjBli*7eJ[iu\>#d.:Q1eJ(KRI!WtP2t6cF$I5-MWj#kD2'
|
||||
n9G:;L6fB+>a&-poO`6CIEGWJFO-)TEOnFbL\O9ha-*Y0]7$[!+=_o#n<?Aae%o</
|
||||
aKluW.8F#/)-%(ONL`)+YS?m:ARn/[M)fB:(TT>DH%"]"B;Cg4#W'h/U4r@L,%<S8
|
||||
C"5aXfjq=C"M#H_NtXil+K]/VT",-q9!NE&Yk%uUlH<s+Y)/i&<SA/.B..1"7oH@o
|
||||
\[,9*)#dn"E<J:'[pSbk+HD&eUsgG&iW&#ALChSHF`#(IcUiP/^YkF-k8Ns(LmZ,`
|
||||
8`"-`I^+2EpoDJ>M#WN^1!aHehs%nZ`2aOo*cQK0*o"G*_s=VM]?#EK8M/fboBE'[
|
||||
D8XD3:Yn[1$"7&LYckl4<pJW-ij0-&Bt;YM.M8:]hF8`M<S2e#h/-Pu^0,h)W6X"S
|
||||
U\n?T1@m29h8cO."3\Mhj:Lu")ABJErjhfO#D.d;+RhWj&n#16bJ_'Rr.3s#@&8Fs
|
||||
9</"JV#1oe<s+$fFJe4<;G"828ZO[R9W]KE#WS!W\gD-_R1o^YiNYP42Oqe;q6&m6
|
||||
s42i,P@8th5r:O:4PDh"0qeND5+WB!=PDu&=]0Kr1fa*-enX3iF1^52_;>knBlLX]
|
||||
BLYm2@F(WF!\al%Rs4(m6,N3LP/lTl/J5a?Gd2W>%PMD$3$o1eOVFHAW'86@Lq/ae
|
||||
PoG]<!?0ND3p&uD,_aDaI4)seP\M_3-6QSfXhedD_F\16HC/)@KkRTj!)>$O["7%9
|
||||
D6B5)D40SQUj"t>'sP,GBNHcO_@C;#b4Y/s#/"Q=JK#Z6aoL"/UN22;/ICc%Ue"uB
|
||||
]?c8;r^8O2Gn1@s^['02cR?WTXYaq/ld"*4j3n6hI:ur.qDG(lF-1K[aj&iIf8Zb6
|
||||
Or[i<?g[<aqu7aROUer
|
||||
~>
|
||||
grestore
|
||||
currentdict /inputf undef
|
||||
currentdict /pstr undef
|
||||
Binary file not shown.
@ -1,143 +0,0 @@
|
||||
%!PS-Adobe-3.0 EPSF-3.0
|
||||
%%BoundingBox: 0 0 594 282
|
||||
%
|
||||
% created by bmeps 1.1.0 (SCCS=1.73)
|
||||
%
|
||||
/pstr
|
||||
1782 string
|
||||
def
|
||||
/inputf
|
||||
currentfile
|
||||
/ASCII85Decode filter
|
||||
/FlateDecode filter
|
||||
/RunLengthDecode filter
|
||||
def
|
||||
gsave
|
||||
0 282 translate
|
||||
594 282 scale
|
||||
594 282 8 [594 0 0 -282 0 0]
|
||||
{ inputf pstr readstring pop }
|
||||
false
|
||||
3
|
||||
colorimage
|
||||
GhVOJCMt3EF[JG%)$pqO7S(n%G(K^F;`(G8(XOELP.48L(.b+8Ob*4)ImDCW62R>Y
|
||||
5HGO<Fr1H]>/u'-DC`Yb)[DB4)jR6jITs'/g5KaoH;L?XMWU?Y2nS3s=$,-(cJ7Tn
|
||||
YBfKkRG!i0]/-cTO*_rBhK-t*kM//,dl$1+3UP^>^A=DLhS%e1RVVcTmH/coI^_2p
|
||||
-/A)fY!:s%S!R6CL[OJmLso/T9kVT@SOM-<O.4GdDT?Ibc$/qg%i@"6-bO49Co>.P
|
||||
"#a4/jnkLEcag/sj%jS#:OH52=nG\2FV0B#(d/l[r=F$/4Qhlj2FFL=Hhc&;&J`$g
|
||||
e/#mQQ%%cA4[bE&c?USiST&@qHQeW6Q<1<?3l70B^)I">&A7>i*.RhB&kZqmpiuqT
|
||||
;(;:1\^[8F`<fe<)dDm.L73akH"7:CV3Kg[r._&+4FZ(9HW8l3<+74k&%JL^0ok15
|
||||
[,a]$bn\sQcP$*%^M7Lam>q*%ek]FmNu1&pA5S"U,JuZG85EA52-4j+Fa)>Q]WpUj
|
||||
-c\0AUZjm(rgK(!Q'CJUfn"L/+)^cpr0ER@>F\KtL:]+M%t+>D*CI0*(eUl!(XEHC
|
||||
$I9(6CE)"1Ous8io0`ntb7#Cg$&"&X9J(K:5Un!<:QB?a8(2a0*")gtAsRsn%p7_Y
|
||||
jHp%:/!9qS_<='I%A-l7LCc&1FrQqV[ZM!=1G^WceO%6YV*a`XLa9B7m^LNMqdY3'
|
||||
Q4<UR>^+0us6$rO^61F>EZnab:b1so.b)bf>Uo!B#Y'gi7FN_'.$fHM3n_"O`l(oW
|
||||
(Ph(J+H_ZdYbETV;*h>J]RD]U)MoC-)+9`C6jcNt=$"H,Yfb*#M/"S=ag+N;<)?)&
|
||||
/9*T#H2)>tq!dT0(po?TZI>;oH"-D60R!510A=+28p4MPmT29j@+ZGDPQChf'`4_7
|
||||
=89;sc_'deo<oChZ)I/0[+cegDPUat-1,bme6"/p$>N#m[0q+I,atN[9.Q94$\_&3
|
||||
g,5;nh9*RoFNa_4=gkG/akK[bc9hf.L^N%j_+MVk($!c^@@GEhD5&>b2'm@d[B;nR
|
||||
%]d"=L=Bg0GjGk))]]eG0VW]DA4A/7>a9V=6G]9H!<d(q')["DlRGP3ED_BA->`q6
|
||||
1*$1JTu:\fnZ8ssn>ri7:2H]'6LgW:%,TmWcA.k.S@0X)P)*g&E>k`Lc'B-oD;ASY
|
||||
\eH:KVUM`<Q;^gr))B8ii/#ab0\*N+iNOB"GcJ0%LpC%*TY,;f<5MddGepP%O+%Y9
|
||||
AjN/MkB<YK*'Ljm]G`d5$q;`&[Nf;5#^_2U>Y=D7fEPr[<7W\W<onQqh6!I-?lObi
|
||||
Y]k,^2CKMYm4=J!Z'tQIOdNT8UZjP"TO4$g7Ba!ZqVP7IOU>hlk=@qY%Z_W$65f7>
|
||||
>bumq/d5R@&L^V)(kp'eRQC%t"`ZMg$nP/:[me8R6oURfnU^pdf*J<%JP-E.(n'\G
|
||||
&T6V'%gFZ8,#.H4JlulYG"<7("BC^WH]j3$J(>cAdkn-JkXrB*N2'8P&Tc6U9!),j
|
||||
.lrFf.T_4J\7QJEm0ZgoF>BOm/j;ipaTXksiF>E+>bPYX[9Q-!s"\QRfG?fmX?D@O
|
||||
$U*EpT?\k`J#-&`7pJ2>9]dJEI8:*F+]#k+^("B5?%lIB$$MG(=I<++YF&4(1YTjR
|
||||
IY1'5c,%T(]:3sl,,Ptq-Q2],6>cB_d(G(@ppOkK!Lb?Sl_&malpO"Ur>r<LlqCbE
|
||||
Y,t<i=&:D.LPi]7!L('\JhlJF!'p(4GJoN0ZY$U.`C,KS33a#@!XF%gT=1&SqgY>0
|
||||
`I@cjN53uiGuEuEIF?[28aa$G3<"j_WhreS'6pH%:mVSSN\6D?VPEA<enH"s"<et.
|
||||
`O(hZVPZVYBNJ-pZJ-9o7o/`rh%])C0XqtXX%5H>AL*-kX<o3N4+`p@,+l!eEWrkF
|
||||
dj!:`Wf\]:KA+jCf;[[ZMV+_lQ\d!7$'ulaoWfTm`d1=%P-_3`Zsi,>"p9EB_gWuC
|
||||
"9mEX22$/=k[#nS+-W!M_FduS+a6&ciEji'TPX%VI>F0$3:N%,KSVuOL,^1T8WeiS
|
||||
Eq.?kX!_aE]YOp$pN7\l/!Op+0=+>"F7uQ"5_hT+WO.%D-h.d#R>AM:XF%Bf+hN8g
|
||||
H^:'D-Ai+9b@(JuGR:>-,Xtj=FK;"KKsS-21jJhh#:2]rHL\m\3Na&hE`G+o<UNk@
|
||||
D8k%@&DMUa#>ga1QmU]E/%/S(_Yq;!=4%>MIF;'6-+R]2iFo(s8#V<^h/g[75cqOP
|
||||
_-WdW[-#A\QLk&eQ)G&,lO6Y2];anIYbMt#i&a"U@OHYclJ\>1$@(,1/;ip=,lhea
|
||||
rY<T\=,YQ\>X]#uraYLc@4LLXW)YUtb`6@l$"'pt9q'U_%<jH;_^l::>_(n6^=\mO
|
||||
^aMLr5t>ff79.tWd"ot@R>OP`OC97]Xk"G7em4.\YfVn#Xb%?gW4$HQei'Z!8b#mT
|
||||
'->:W8(Bp&^nJNnX1E\Aeq!ae=_6G3RoB/=]&=>Z>_qW2`=O"X2m_f`!XhS'"ThQ:
|
||||
mGNVkdDWb)#&q]OjM6@dpS*NB%*5:(#+0eS3O2upb1PR*B$)/X:j\1rc)*T/*#Sl>
|
||||
PAg#j*b7l<m#u1WB@/Xg9uY2jN]ll(=M=?!01\0Ij$>Ei3?;TnTNlJ9aEF)DF!ggJ
|
||||
R:F&'IIpSi1K(6Tg9,i[Vf:jOE?go3\ngpJ*lo9WnR!ZA/e]m4Gki4(N?hB/Ms?Le
|
||||
l)kEO,RsL@$&'9S,d]?(A+>W]nA1;K&im@`E+JF1\AmWZUgTKnmU-=]`%68V`W`[V
|
||||
i`7;mVI^:ke=D\U-nR5jn:'T+\?LoHne/(&j4d;fWH<R*#;[&DPH3E;XZr"A]q[PC
|
||||
/C(>[pZanm"(s1<R8r=Qfoj3?<k@&*8O,tL4WiGj0=8Ag*1Q&X?E1uh8=EK?,;ka3
|
||||
_]6kg#.GodeMLWji]/jmpm$CIX='YmVIsi*A8f\%]/5n^mMs#mqV$J38&FZ=i6P:N
|
||||
XXpuaTerLh^cVfMJp\mZ>_T?dkDF+rB$U\=OE%To=WP.=b1sKmKW,D$SjIXsJ*mUQ
|
||||
B`R:NmJrLqfPt;-+b;+`p).=o!nVR.,Mc72>s(A+4"e$kna]1,+tp#ugD$MOcEQij
|
||||
R!mceFd;q6Rf^_ZR^D$aqQ@+,Y:sPe\5Y'4FM5Yn@&i4]eQ,hLl(9Y@iQ&l+NE9rL
|
||||
Z+eUh9s^1alX^fNbd_soRSMH:9;\G"CbSNHIu%c"A4;3L\%*Pfka]S9ZIo^nY`_,f
|
||||
qp++X>?X3#`N1$aVUgZek:EO'Rc^e.8he$G4@a"QO_0ZW7.-\#DP\CY2?4[u_F4"I
|
||||
KIIloF1bT8I)1C?a]:pP6peqn!V6r-Xt;Vf3^\o\$/#DtFEaK*MIWZhNP!;]g3;0c
|
||||
cR`Y.-*G,YVPEW9^S+.+\DaVe6N$psR,S98OWCQtGH[M>&J`sHA?`Iog[gLb!qG_-
|
||||
MfFZIVn"coLZU(T9(SuRhAL%O&CIa8dDfWaIpm?H'LSS,`cnkk4oo5Y31l\a%O2Y9
|
||||
3%J+2XFY7oiC^hCPR6o?r&?H(Mih*<C1$@`I4C5%.SBR!Zj3!APAS03QH:fMq[`;H
|
||||
![kG;.JZa#Ic:4?Hg0k1!VE(7Sk`J&pa0:Tie4i(F-D;_J^:o#o%Th&\%n8?P9mq/
|
||||
:&'2.9<T]j5l0JWG*Sl).PJe:iq]j`(Ai*6)g!Oo%EOOLc$Z2Pb2#Bh>-J=e.PLcN
|
||||
([EM%1X`_!GF:CRc.Rl7Xr$'DVhsFQ]>5n)Rs>@..p-XfB;J"36e^UmJ9AEN)>[+f
|
||||
1pR'Y)$a9O_%o$69ANMFJL(]4Tr7#"^:D6X;dH"IP&YCj$g_MEM+fgQC`5JVlE%3u
|
||||
SIj:Ui@Z>BZYsX5iWXUhf*jiRif9(#l6D6NW4g@^7nNr(p&:?@a+G%5q'<6GYdF19
|
||||
:Lom#ZBENTHrO_+-.T9jdA5_E(fbuGn+LDEO!$<uS]L*\Bt0'8/(?B'![QPs8R%oG
|
||||
C\3d%`b%=-GW`Hs)*u`^L4chPL=m?pU[X9qLoIOr_Kkkq=2f$AJND]4a&=['\/<k2
|
||||
e(dS4&iK0F]rQghWrfk^Qi#7d`5A4=cSl*nA*]r(rdBm#9;r8m<ng.M3_a=3]%'!N
|
||||
VWGd%Ol!?/rauRiMUOUp;I3TV<1YM,SBTUbrV#s`L0rhlG3L&+H:!d_XTdP2Y2&10
|
||||
QSkJ%dYU@V-`frU-b3=.ER\X-$?'_gs'>H;>A%gB`EUC56"r)IO&;3,Oc>22+HgbD
|
||||
>/%M_hi*AbnX_Qc!4DrBZ27ZkV?U:09J.TEgnuL$+a8e`NmdEB.RT\8NRd%_At,pq
|
||||
^H#Bi!kSp)?W(*&a&H_@\+)kIAHOm%EOuiWQI9.)pQe_30/en\?FIt-3BMrEMmi97
|
||||
7XXnOd(T&A^pg5&*3M)(pWN!@)Xl;K(U[%r^1/9pf+j%g\,.np")7LRE?T[3(:(Jj
|
||||
G-LGeaqVeoW(VI%.M^;G(P6*f*?BT`Y8;M</Y8e3mU2<R>r#o<@$*5:c2:Qj1VP@L
|
||||
RK;"n;!ubUIGH=[$\>Db[0@H0lUK!Ur9L0s*#E>-l86`K?^KZodfuor^4E[D/G=&o
|
||||
$0Wg`4<O_O7?-Z.CK"B_T*)IpY?1.QC)`!llng@<M0CHM7n6&C6f&^8nhL_I$UX'D
|
||||
Le+,d3'-r<D@e/SWSr8kqa9(R11CdUUUmbWH:97+f*"cnE8[l,Ii\k($i"O*X]pCE
|
||||
s(5]"P#H=+,tJu?>U-sno8knk:U#AW7i$c3bJMh^8"d_Q_3Ni.')k9[::#iF9%?kI
|
||||
C%UTM]49^WmlkccB4VHs'RAf&'B;DE#_[ceHF^[umAE8<5Rrg2*emIfXp<<4/_dZN
|
||||
qq8FcG"A2;k5tB[ieJ02Cl<5&&o4KL\lgW[V)fARTVBsErZDT@BbcsrmeG@03'Bhd
|
||||
_h%fir'JA>E.YYdBeB$d4SBD[90p`);^QV"%-Hu2Im;D;YQGqEX0n>/UQpuBZNOod
|
||||
81QBU(W;HYE8cmaXJb:LG/'r1CoX5UpW)W:IdB22\!J"@pig/8F=h`E&.eqr.kf?J
|
||||
`h`CSMWb(kabRo>58.d/e'W'@dQqoQ`Cq3;p-Ljp0*pmY:QCJD1]3`:5F>/\jI&gp
|
||||
>bCD7Nqb"cpS1<WSaUrK88E$pqV>"d$Q^\c$utg#f7XXQ=4\#Kb>WH>Qia>mShr-B
|
||||
C-b3AoaQnN<_l;0'7M;:$RG#O+/tcRUZW2p^AsS``%irLO<I+Bq;.jt9m''60J)'P
|
||||
=7+HtocBFK`>I,UMf?0VAs@4"B2VZg#e(6A4m,'*cNPU+;j;gPhl24@(@q4N*,W>9
|
||||
iDO"j;PNZ8o!W"9.SEQ>RAp:iJeN/5mL5LPV(;sn[cB!).AoT*,IbhGGMboXX(d-Q
|
||||
E\J_MK=a0P5?F-to@[5l>pq(PZPs=fY`l$oQNRo`1l]OeK3_OV^P.OFX"C(WF:T*C
|
||||
b^5X'R?4kn"q?oq&KcqRmpR@?oQOPBp8oj!o!u4uXQ0o4+M/f?M0AC#`k0c'5'ptk
|
||||
qBCHb,[:hE2"#aCL%Q43U55so`)f0q'iu^clK0sGqd"4u=J6m%6-S[og4T;aQ#3Mf
|
||||
Bg([7(%`"^2lraoO4T;+H@^sD\pimLfhN-#\'><mYO,^>p_P'8FOBjfUidOC8rsuK
|
||||
hBbt<mAYZa5776%8GNG>7SKc:<h;PC(nOt;gmgH[309@U3%cO!q^;i9q:(5;jQG[)
|
||||
WbemcS"dr`89+;#)ThXeD6(h-Z$kd[ED=mi51c\;<fAgMR(Ao"PKeu&+\``%Ia,lO
|
||||
+-\)bW/[*5ba<A2hYY@(iH>g9L7om2s+r&^b'+=uQYLf"7gJ]@(\RaMdcVC:_J^n>
|
||||
P,DFkJr2fUV$KZ,$)!imU(ZmHYD\rF5Up,lEcYRS00f9!9D_AADDCO^$BP\n.a9D/
|
||||
'/=8^%ms_kQi1]kg<=Vmq5Vd+Uus5s:k`"^I7`V<S>><!)KiLI,jIERs$ME+$opeg
|
||||
d$FdH+J2=Z@(2t@a$ITnCrYJ`/;aba9U=lM.<@n9d@Db25X$t^UE,6))-MAP@VOg2
|
||||
[7t*Dkt;,o:2hFbn%Os*7iu;@s7nb^2WCOM-,[Tfb*!C_(B!tgdh%8G\$`:9IARMs
|
||||
U,!K54=u%r>%=i5!s;J?"5PWnj)-o=UH#>Hs!7A<HT^Tt?VI@#b4$cY')fD:rX4!5
|
||||
b@YaG`ZJeDIN>F&*+`-_[!QAjl%\u)U^O2OaD?N(Aa#\18DhP%D=#[7(549JWT$EQ
|
||||
_Y:*V`DS>JR7*Z<3tdr2]]-n[T<8l3V9l7?UguVM(]87eA'/CZl8m6#8L!-f9cc@O
|
||||
AA_jAMUtpuFjXJl7!JD0;4aoKVY'i!j$jn4k=@7Ub4V=UR%D$J*.T<3>XBXM<,(cT
|
||||
IN#V27&Pq/6,Tm3$Z635V92_PC\;gTr`Z",dd<Z<Y=BLK\LFTUTf(d)7's$*L=)Pc
|
||||
GrJBF.uj9Jj75a#k`GGKP#UaH3@8LgrQ]r]?Pgk%C@ZX&8Ut.m9&KmDSgi:aS13^!
|
||||
H8o'%\G]CT9f\t+Bs"mo&=k;Bi<$SnW->>Wb;%^HAUjNN<?ro4TIE$u;`Eh?4u;jl
|
||||
0K)_l/YP7/&?U8#s7XH!_=P-DUKJlq;@@V=)q<YE?/u$*c]dB.da<0.*oDrY2`:Z7
|
||||
,8sn"ro4B(%m'\Eh)u"u,GogdUX\qHRpGJ<gtkHroAMmo9).]Z3SOl7Dh\'Go`$DQ
|
||||
s"2iF,.`28#*ajLq$p&%A^<eE/VVq9/)tLG3_=FS(KLtt)e(ZL?qXk!l\.<Dm(TOa
|
||||
%/u%NLp._;_.e9A3^rN&OE0bS04`,b78MbDY'D1]G7_t@b\;#l#BAu83l=U97#Q6s
|
||||
^m=N1;!pkDRN<]l3n!%E$A#D_Hqc'=L=5Tj%8cb.9#HM<iu>%m@j7g^!9Sh_OH;p9
|
||||
,$LfBr"bj^kc)Y@1-F&q;A5]]U71s#W+%O`*pP#`DL;M[".mNRbD>?gn5.s!18i5m
|
||||
Sci[q3j0]ZhG2f[7E4,]49dL-TM>o9\jked-_i$VP5k02]>-G\J)PIY3^WBu6AM'X
|
||||
s.`*Q!&`q;DRenNLH_gAk,=k[icc;s6r>3gf\Hq68Gkbei>4TADbcJKeTLKV<Heml
|
||||
[7QCFaRNp(Ld)E3H[F',BSN?H;SlH$<M,N1F$9R>b$\SKJFf=a@%A&3oeW8g$6/'L
|
||||
jAj`mid;ea-F@GF>=7F_hjG.L187EmeAG>_0IifNMHC>fcc;+jK:CCRO3(X!,SQM$
|
||||
S!hdF/7`cDOh'unOb/XJ>8f75ag:KICueG\TgNA5-IAeq<-%NX,,W;+/.6i6o2*OL
|
||||
;G')Pl&"biOff@qN"9`q%O22D>;"YnAsfr'YW7`6[/o2tX!T=]><jiZ&k52>-^t+_
|
||||
e6G[MD7k1":h"T]M:JOLW_SG&L+*;<$HsODi9CmGge:_J-e/D2BrfiS`[.un2`4'a
|
||||
MseCj-YdUAWI*PMUTKfejB.g$,:g+C6Tr<t8"%"+Lb.QPcI2;,)2#^uhs4\1KM:-"
|
||||
N*KV.*F,6*UO"WnaX,"$.ML5cb91TkX"(1P#D"C+f,Et3*p])_+qFE/hJ6=6Ts]^!
|
||||
_la#r2go;KYO]p4l0?%d68`)T^q,?BHcZm?aSTJ!iq7tu)7:;"9Zchp:#s$5OPt`i
|
||||
]B#Q0_K-7,^oRWLlUdkF9dHIkFn)pIT="^BKY51IZKDf)^W1fFT@;lX=3/j'^fZPF
|
||||
VQYR0O+4`aDh"C[p\mCpac"F
|
||||
~>
|
||||
grestore
|
||||
currentdict /inputf undef
|
||||
currentdict /pstr undef
|
||||
Binary file not shown.
@ -1,463 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-2.0
|
||||
%%Title: interaction.fig
|
||||
%%Creator: fig2dev Version 3.2 Patchlevel 3d
|
||||
%%CreationDate: Sat Jan 31 05:25:23 2004
|
||||
%%For: nickm@totoro.wangafu.net ()
|
||||
%%BoundingBox: 0 0 449 235
|
||||
%%Magnification: 1.0000
|
||||
%%EndComments
|
||||
/$F2psDict 200 dict def
|
||||
$F2psDict begin
|
||||
$F2psDict /mtrx matrix put
|
||||
/col-1 {0 setgray} bind def
|
||||
/col0 {0.000 0.000 0.000 srgb} bind def
|
||||
/col1 {0.000 0.000 1.000 srgb} bind def
|
||||
/col2 {0.000 1.000 0.000 srgb} bind def
|
||||
/col3 {0.000 1.000 1.000 srgb} bind def
|
||||
/col4 {1.000 0.000 0.000 srgb} bind def
|
||||
/col5 {1.000 0.000 1.000 srgb} bind def
|
||||
/col6 {1.000 1.000 0.000 srgb} bind def
|
||||
/col7 {1.000 1.000 1.000 srgb} bind def
|
||||
/col8 {0.000 0.000 0.560 srgb} bind def
|
||||
/col9 {0.000 0.000 0.690 srgb} bind def
|
||||
/col10 {0.000 0.000 0.820 srgb} bind def
|
||||
/col11 {0.530 0.810 1.000 srgb} bind def
|
||||
/col12 {0.000 0.560 0.000 srgb} bind def
|
||||
/col13 {0.000 0.690 0.000 srgb} bind def
|
||||
/col14 {0.000 0.820 0.000 srgb} bind def
|
||||
/col15 {0.000 0.560 0.560 srgb} bind def
|
||||
/col16 {0.000 0.690 0.690 srgb} bind def
|
||||
/col17 {0.000 0.820 0.820 srgb} bind def
|
||||
/col18 {0.560 0.000 0.000 srgb} bind def
|
||||
/col19 {0.690 0.000 0.000 srgb} bind def
|
||||
/col20 {0.820 0.000 0.000 srgb} bind def
|
||||
/col21 {0.560 0.000 0.560 srgb} bind def
|
||||
/col22 {0.690 0.000 0.690 srgb} bind def
|
||||
/col23 {0.820 0.000 0.820 srgb} bind def
|
||||
/col24 {0.500 0.190 0.000 srgb} bind def
|
||||
/col25 {0.630 0.250 0.000 srgb} bind def
|
||||
/col26 {0.750 0.380 0.000 srgb} bind def
|
||||
/col27 {1.000 0.500 0.500 srgb} bind def
|
||||
/col28 {1.000 0.630 0.630 srgb} bind def
|
||||
/col29 {1.000 0.750 0.750 srgb} bind def
|
||||
/col30 {1.000 0.880 0.880 srgb} bind def
|
||||
/col31 {1.000 0.840 0.000 srgb} bind def
|
||||
|
||||
end
|
||||
save
|
||||
newpath 0 235 moveto 0 0 lineto 449 0 lineto 449 235 lineto closepath clip newpath
|
||||
-62.3 239.8 translate
|
||||
1 -1 scale
|
||||
|
||||
/cp {closepath} bind def
|
||||
/ef {eofill} bind def
|
||||
/gr {grestore} bind def
|
||||
/gs {gsave} bind def
|
||||
/sa {save} bind def
|
||||
/rs {restore} bind def
|
||||
/l {lineto} bind def
|
||||
/m {moveto} bind def
|
||||
/rm {rmoveto} bind def
|
||||
/n {newpath} bind def
|
||||
/s {stroke} bind def
|
||||
/sh {show} bind def
|
||||
/slc {setlinecap} bind def
|
||||
/slj {setlinejoin} bind def
|
||||
/slw {setlinewidth} bind def
|
||||
/srgb {setrgbcolor} bind def
|
||||
/rot {rotate} bind def
|
||||
/sc {scale} bind def
|
||||
/sd {setdash} bind def
|
||||
/ff {findfont} bind def
|
||||
/sf {setfont} bind def
|
||||
/scf {scalefont} bind def
|
||||
/sw {stringwidth} bind def
|
||||
/tr {translate} bind def
|
||||
/tnt {dup dup currentrgbcolor
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
|
||||
bind def
|
||||
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
|
||||
4 -2 roll mul srgb} bind def
|
||||
/reencdict 12 dict def /ReEncode { reencdict begin
|
||||
/newcodesandnames exch def /newfontname exch def /basefontname exch def
|
||||
/basefontdict basefontname findfont def /newfont basefontdict maxlength dict def
|
||||
basefontdict { exch dup /FID ne { dup /Encoding eq
|
||||
{ exch dup length array copy newfont 3 1 roll put }
|
||||
{ exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall
|
||||
newfont /FontName newfontname put newcodesandnames aload pop
|
||||
128 1 255 { newfont /Encoding get exch /.notdef put } for
|
||||
newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put } repeat
|
||||
newfontname newfont definefont pop end } def
|
||||
/isovec [
|
||||
8#055 /minus 8#200 /grave 8#201 /acute 8#202 /circumflex 8#203 /tilde
|
||||
8#204 /macron 8#205 /breve 8#206 /dotaccent 8#207 /dieresis
|
||||
8#210 /ring 8#211 /cedilla 8#212 /hungarumlaut 8#213 /ogonek 8#214 /caron
|
||||
8#220 /dotlessi 8#230 /oe 8#231 /OE
|
||||
8#240 /space 8#241 /exclamdown 8#242 /cent 8#243 /sterling
|
||||
8#244 /currency 8#245 /yen 8#246 /brokenbar 8#247 /section 8#250 /dieresis
|
||||
8#251 /copyright 8#252 /ordfeminine 8#253 /guillemotleft 8#254 /logicalnot
|
||||
8#255 /hyphen 8#256 /registered 8#257 /macron 8#260 /degree 8#261 /plusminus
|
||||
8#262 /twosuperior 8#263 /threesuperior 8#264 /acute 8#265 /mu 8#266 /paragraph
|
||||
8#267 /periodcentered 8#270 /cedilla 8#271 /onesuperior 8#272 /ordmasculine
|
||||
8#273 /guillemotright 8#274 /onequarter 8#275 /onehalf
|
||||
8#276 /threequarters 8#277 /questiondown 8#300 /Agrave 8#301 /Aacute
|
||||
8#302 /Acircumflex 8#303 /Atilde 8#304 /Adieresis 8#305 /Aring
|
||||
8#306 /AE 8#307 /Ccedilla 8#310 /Egrave 8#311 /Eacute
|
||||
8#312 /Ecircumflex 8#313 /Edieresis 8#314 /Igrave 8#315 /Iacute
|
||||
8#316 /Icircumflex 8#317 /Idieresis 8#320 /Eth 8#321 /Ntilde 8#322 /Ograve
|
||||
8#323 /Oacute 8#324 /Ocircumflex 8#325 /Otilde 8#326 /Odieresis 8#327 /multiply
|
||||
8#330 /Oslash 8#331 /Ugrave 8#332 /Uacute 8#333 /Ucircumflex
|
||||
8#334 /Udieresis 8#335 /Yacute 8#336 /Thorn 8#337 /germandbls 8#340 /agrave
|
||||
8#341 /aacute 8#342 /acircumflex 8#343 /atilde 8#344 /adieresis 8#345 /aring
|
||||
8#346 /ae 8#347 /ccedilla 8#350 /egrave 8#351 /eacute
|
||||
8#352 /ecircumflex 8#353 /edieresis 8#354 /igrave 8#355 /iacute
|
||||
8#356 /icircumflex 8#357 /idieresis 8#360 /eth 8#361 /ntilde 8#362 /ograve
|
||||
8#363 /oacute 8#364 /ocircumflex 8#365 /otilde 8#366 /odieresis 8#367 /divide
|
||||
8#370 /oslash 8#371 /ugrave 8#372 /uacute 8#373 /ucircumflex
|
||||
8#374 /udieresis 8#375 /yacute 8#376 /thorn 8#377 /ydieresis] def
|
||||
/Times-Bold /Times-Bold-iso isovec ReEncode
|
||||
/Times-Roman /Times-Roman-iso isovec ReEncode
|
||||
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
|
||||
/$F2psEnd {$F2psEnteredState restore end} def
|
||||
|
||||
$F2psBegin
|
||||
10 setmiterlimit
|
||||
0.06000 0.06000 sc
|
||||
%
|
||||
% Fig objects follow
|
||||
%
|
||||
% Polyline
|
||||
15.000 slw
|
||||
n 6000 300 m
|
||||
6000 3975 l gs col0 s gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
gs clippath
|
||||
3615 555 m 3615 495 l 3464 495 l 3584 525 l 3464 555 l cp
|
||||
eoclip
|
||||
n 1200 525 m
|
||||
3600 525 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3464 555 m 3584 525 l 3464 495 l 3464 555 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
1185 795 m 1185 855 l 1336 855 l 1216 825 l 1336 795 l cp
|
||||
eoclip
|
||||
n 3600 825 m
|
||||
1200 825 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 1336 795 m 1216 825 l 1336 855 l 1336 795 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
15.000 slw
|
||||
n 1200 300 m
|
||||
1200 3975 l gs col0 s gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
gs clippath
|
||||
3615 1155 m 3615 1095 l 3464 1095 l 3584 1125 l 3464 1155 l cp
|
||||
eoclip
|
||||
n 1200 1125 m
|
||||
3600 1125 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3464 1155 m 3584 1125 l 3464 1095 l 3464 1155 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
15.000 slw
|
||||
n 3600 300 m
|
||||
3600 3975 l gs col0 s gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
gs clippath
|
||||
6015 1230 m 6015 1170 l 5864 1170 l 5984 1200 l 5864 1230 l cp
|
||||
eoclip
|
||||
n 3600 1200 m
|
||||
6000 1200 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 5864 1230 m 5984 1200 l 5864 1170 l 5864 1230 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
3585 1470 m 3585 1530 l 3736 1530 l 3616 1500 l 3736 1470 l cp
|
||||
eoclip
|
||||
n 6000 1500 m
|
||||
3600 1500 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3736 1470 m 3616 1500 l 3736 1530 l 3736 1470 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
1185 1545 m 1185 1605 l 1336 1605 l 1216 1575 l 1336 1545 l cp
|
||||
eoclip
|
||||
n 3600 1575 m
|
||||
1200 1575 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 1336 1545 m 1216 1575 l 1336 1605 l 1336 1545 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
[15 45] 45 sd
|
||||
n 1050 1800 m
|
||||
8325 1800 l gs col0 s gr [] 0 sd
|
||||
% Polyline
|
||||
gs clippath
|
||||
3615 2130 m 3615 2070 l 3464 2070 l 3584 2100 l 3464 2130 l cp
|
||||
eoclip
|
||||
n 1200 2100 m
|
||||
3600 2100 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3464 2130 m 3584 2100 l 3464 2070 l 3464 2130 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
6015 2205 m 6015 2145 l 5864 2145 l 5984 2175 l 5864 2205 l cp
|
||||
eoclip
|
||||
n 3600 2175 m
|
||||
6000 2175 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 5864 2205 m 5984 2175 l 5864 2145 l 5864 2205 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
[60] 0 sd
|
||||
gs clippath
|
||||
8190 2430 m 8190 2370 l 8039 2370 l 8159 2400 l 8039 2430 l cp
|
||||
5985 2370 m 5985 2430 l 6136 2430 l 6016 2400 l 6136 2370 l cp
|
||||
eoclip
|
||||
n 6000 2400 m
|
||||
8175 2400 l gs col0 s gr gr
|
||||
[] 0 sd
|
||||
% arrowhead
|
||||
n 6136 2370 m 6016 2400 l 6136 2430 l 6136 2370 l cp gs 0.00 setgray ef gr col0 s
|
||||
% arrowhead
|
||||
n 8039 2430 m 8159 2400 l 8039 2370 l 8039 2430 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
3585 2520 m 3585 2580 l 3736 2580 l 3616 2550 l 3736 2520 l cp
|
||||
eoclip
|
||||
n 6000 2550 m
|
||||
3600 2550 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3736 2520 m 3616 2550 l 3736 2580 l 3736 2520 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
1185 2595 m 1185 2655 l 1336 2655 l 1216 2625 l 1336 2595 l cp
|
||||
eoclip
|
||||
n 3600 2625 m
|
||||
1200 2625 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 1336 2595 m 1216 2625 l 1336 2655 l 1336 2595 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
3615 3030 m 3615 2970 l 3464 2970 l 3584 3000 l 3464 3030 l cp
|
||||
eoclip
|
||||
n 1200 3000 m
|
||||
3600 3000 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3464 3030 m 3584 3000 l 3464 2970 l 3464 3030 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
6015 3105 m 6015 3045 l 5864 3045 l 5984 3075 l 5864 3105 l cp
|
||||
eoclip
|
||||
n 3600 3075 m
|
||||
6000 3075 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 5864 3105 m 5984 3075 l 5864 3045 l 5864 3105 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
8190 3180 m 8190 3120 l 8039 3120 l 8159 3150 l 8039 3180 l cp
|
||||
eoclip
|
||||
n 6000 3150 m
|
||||
8175 3150 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 8039 3180 m 8159 3150 l 8039 3120 l 8039 3180 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
5985 3420 m 5985 3480 l 6136 3480 l 6016 3450 l 6136 3420 l cp
|
||||
eoclip
|
||||
n 8175 3450 m
|
||||
6000 3450 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 6136 3420 m 6016 3450 l 6136 3480 l 6136 3420 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
5985 3495 m 5985 3555 l 6136 3555 l 6016 3525 l 6136 3495 l cp
|
||||
eoclip
|
||||
n 8175 3525 m
|
||||
6000 3525 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 6136 3495 m 6016 3525 l 6136 3555 l 6136 3495 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
5985 3570 m 5985 3630 l 6136 3630 l 6016 3600 l 6136 3570 l cp
|
||||
eoclip
|
||||
n 8175 3600 m
|
||||
6000 3600 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 6136 3570 m 6016 3600 l 6136 3630 l 6136 3570 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
3585 3495 m 3585 3555 l 3736 3555 l 3616 3525 l 3736 3495 l cp
|
||||
eoclip
|
||||
n 6000 3525 m
|
||||
3600 3525 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3736 3495 m 3616 3525 l 3736 3555 l 3736 3495 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
3585 3645 m 3585 3705 l 3736 3705 l 3616 3675 l 3736 3645 l cp
|
||||
eoclip
|
||||
n 6000 3675 m
|
||||
3600 3675 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3736 3645 m 3616 3675 l 3736 3705 l 3736 3645 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
3585 3570 m 3585 3630 l 3736 3630 l 3616 3600 l 3736 3570 l cp
|
||||
eoclip
|
||||
n 6000 3600 m
|
||||
3600 3600 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 3736 3570 m 3616 3600 l 3736 3630 l 3736 3570 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
1185 3645 m 1185 3705 l 1336 3705 l 1216 3675 l 1336 3645 l cp
|
||||
eoclip
|
||||
n 3600 3675 m
|
||||
1200 3675 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 1336 3645 m 1216 3675 l 1336 3705 l 1336 3645 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
1185 3720 m 1185 3780 l 1336 3780 l 1216 3750 l 1336 3720 l cp
|
||||
eoclip
|
||||
n 3600 3750 m
|
||||
1200 3750 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 1336 3720 m 1216 3750 l 1336 3780 l 1336 3720 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
gs clippath
|
||||
1185 3795 m 1185 3855 l 1336 3855 l 1216 3825 l 1336 3795 l cp
|
||||
eoclip
|
||||
n 3600 3825 m
|
||||
1200 3825 l gs col0 s gr gr
|
||||
|
||||
% arrowhead
|
||||
n 1336 3795 m 1216 3825 l 1336 3855 l 1336 3795 l cp gs 0.00 setgray ef gr col0 s
|
||||
% Polyline
|
||||
15.000 slw
|
||||
n 8175 300 m
|
||||
8175 3975 l gs col0 s gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
n 6300 825 m 7950 825 l 7950 1725 l 6300 1725 l
|
||||
cp gs col7 1.00 shd ef gr gs col0 s gr
|
||||
/Times-Bold-iso ff 180.00 scf sf
|
||||
3375 225 m
|
||||
gs 1 -1 sc (OR 1) col0 sh gr
|
||||
/Times-Bold-iso ff 180.00 scf sf
|
||||
1050 225 m
|
||||
gs 1 -1 sc (Alice) col0 sh gr
|
||||
/Times-Bold-iso ff 180.00 scf sf
|
||||
5775 225 m
|
||||
gs 1 -1 sc (OR 2) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
6075 3075 m
|
||||
gs 1 -1 sc ("HTTP GET...") col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
4800 3975 m
|
||||
gs 1 -1 sc (. . .) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7125 3975 m
|
||||
gs 1 -1 sc (. . .) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
2400 3975 m
|
||||
gs 1 -1 sc (. . .) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7125 2325 m
|
||||
gs 1 -1 sc (\(TCP handshake\)) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Bold-iso ff 180.00 scf sf
|
||||
7875 225 m
|
||||
gs 1 -1 sc (website) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7125 1425 m
|
||||
gs 1 -1 sc ({X}--AES encryption) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7125 1200 m
|
||||
gs 1 -1 sc (E\(x\)--RSA encryption) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7125 975 m
|
||||
gs 1 -1 sc (Legend:) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
2400 225 m
|
||||
gs 1 -1 sc (\(link is TLS-encrypted\)) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
1275 1050 m
|
||||
gs 1 -1 sc (Relay c1{Extend, OR2, E\(g^x2\)}) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
1275 2025 m
|
||||
gs 1 -1 sc (Relay c1{{Begin <website>:80}}) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3525 1500 m
|
||||
gs 1 -1 sc (Relay c1{Extended, g^y2, H\(K2\)}) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3675 2100 m
|
||||
gs 1 -1 sc (Relay c2{Begin <website>:80}) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3525 2550 m
|
||||
gs 1 -1 sc (Relay c1{{Connected}}) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
5925 2475 m
|
||||
gs 1 -1 sc (Relay c2{Connected}) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
1275 2925 m
|
||||
gs 1 -1 sc (Relay c1{{Data, "HTTP GET..."}}) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3675 3000 m
|
||||
gs 1 -1 sc (Relay c2{Data, "HTTP GET..."}) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
4800 225 m
|
||||
gs 1 -1 sc (\(link is TLS-encryped\)) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7050 225 m
|
||||
gs 1 -1 sc (\(unencrypted\)) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
7125 1650 m
|
||||
gs 1 -1 sc (cN--a circID) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3525 3600 m
|
||||
gs 1 -1 sc (Relay c1{{Data, \(response\)}}) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
8100 3375 m
|
||||
gs 1 -1 sc (\(response\)) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
5925 3450 m
|
||||
gs 1 -1 sc (Relay c2{Data, \(response\)}) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
5925 1425 m
|
||||
gs 1 -1 sc (Created c2, g^y2, H\(K2\)) dup sw pop neg 0 rm col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3675 1125 m
|
||||
gs 1 -1 sc (Create c2, E\(g^x2\)) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
1275 450 m
|
||||
gs 1 -1 sc (Create c1, E\(g^x1\)) col0 sh gr
|
||||
/Times-Roman-iso ff 150.00 scf sf
|
||||
3525 750 m
|
||||
gs 1 -1 sc (Created c1, g^y1, H\(K1\)) dup sw pop neg 0 rm col0 sh gr
|
||||
$F2psEnd
|
||||
rs
|
||||
@ -1,122 +0,0 @@
|
||||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 1 0 2 0 7 50 0 -1 0.000 0 0 -1 0 0 2
|
||||
6000 300 6000 3975
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
1200 525 3600 525
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 825 1200 825
|
||||
2 1 0 2 0 7 50 0 -1 0.000 0 0 -1 0 0 2
|
||||
1200 300 1200 3975
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
1200 1125 3600 1125
|
||||
2 1 0 2 0 7 50 0 -1 0.000 0 0 -1 0 0 2
|
||||
3600 300 3600 3975
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 1200 6000 1200
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 1500 3600 1500
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 1575 1200 1575
|
||||
2 1 2 1 0 7 50 0 -1 3.000 0 0 -1 0 0 2
|
||||
1050 1800 8325 1800
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
1200 2100 3600 2100
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 2175 6000 2175
|
||||
2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
|
||||
1 1 1.00 60.00 120.00
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 2400 8175 2400
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 2550 3600 2550
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 2625 1200 2625
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
1200 3000 3600 3000
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 3075 6000 3075
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 3150 8175 3150
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
8175 3450 6000 3450
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
8175 3525 6000 3525
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
8175 3600 6000 3600
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 3525 3600 3525
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 3675 3600 3675
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
6000 3600 3600 3600
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 3675 1200 3675
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 3750 1200 3750
|
||||
2 1 0 1 0 7 50 0 -1 3.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 3825 1200 3825
|
||||
2 1 0 2 0 7 50 0 -1 0.000 0 0 -1 0 0 2
|
||||
8175 300 8175 3975
|
||||
2 2 0 1 0 7 50 0 20 3.000 0 0 -1 0 0 5
|
||||
6300 825 7950 825 7950 1725 6300 1725 6300 825
|
||||
4 0 0 50 0 2 12 0.0000 4 135 450 3375 225 OR 1\001
|
||||
4 0 0 50 0 2 12 0.0000 4 135 420 1050 225 Alice\001
|
||||
4 0 0 50 0 2 12 0.0000 4 135 450 5775 225 OR 2\001
|
||||
4 0 0 50 0 0 10 0.0000 4 105 960 6075 3075 "HTTP GET..."\001
|
||||
4 1 0 50 0 0 10 0.0000 4 15 135 4800 3975 . . .\001
|
||||
4 1 0 50 0 0 10 0.0000 4 15 135 7125 3975 . . .\001
|
||||
4 1 0 50 0 0 10 0.0000 4 15 135 2400 3975 . . .\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 1050 7125 2325 (TCP handshake)\001
|
||||
4 0 0 50 0 2 12 0.0000 4 135 630 7875 225 website\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 1335 7125 1425 {X}--AES encryption\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 1410 7125 1200 E(x)--RSA encryption\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 480 7125 975 Legend:\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 1455 2400 225 (link is TLS-encrypted)\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 2085 1275 1050 Relay c1{Extend, OR2, E(g^x2)}\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 1965 1275 2025 Relay c1{{Begin <website>:80}}\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 2190 3525 1500 Relay c1{Extended, g^y2, H(K2)}\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 1845 3675 2100 Relay c2{Begin <website>:80}\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 1410 3525 2550 Relay c1{{Connected}}\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 1290 5925 2475 Relay c2{Connected}\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 2085 1275 2925 Relay c1{{Data, "HTTP GET..."}}\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 1965 3675 3000 Relay c2{Data, "HTTP GET..."}\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 1365 4800 225 (link is TLS-encryped)\001
|
||||
4 1 0 50 0 0 10 0.0000 4 135 870 7050 225 (unencrypted)\001
|
||||
4 1 0 50 0 0 10 0.0000 4 105 780 7125 1650 cN--a circID\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 1860 3525 3600 Relay c1{{Data, (response)}}\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 645 8100 3375 (response)\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 1650 5925 3450 Relay c2{Data, (response)}\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 1545 5925 1425 Created c2, g^y2, H(K2)\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 1170 3675 1125 Create c2, E(g^x2)\001
|
||||
4 0 0 50 0 0 10 0.0000 4 135 1170 1275 450 Create c1, E(g^x1)\001
|
||||
4 2 0 50 0 0 10 0.0000 4 135 1545 3525 750 Created c1, g^y1, H(K1)\001
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,353 +0,0 @@
|
||||
\documentclass{llncs}
|
||||
|
||||
\usepackage{url}
|
||||
\usepackage{amsmath}
|
||||
\usepackage{epsfig}
|
||||
|
||||
\setlength{\textwidth}{5.9in}
|
||||
\setlength{\textheight}{8.4in}
|
||||
\setlength{\topmargin}{.5cm}
|
||||
\setlength{\oddsidemargin}{1cm}
|
||||
\setlength{\evensidemargin}{1cm}
|
||||
|
||||
\newenvironment{tightlist}{\begin{list}{$\bullet$}{
|
||||
\setlength{\itemsep}{0mm}
|
||||
\setlength{\parsep}{0mm}
|
||||
% \setlength{\labelsep}{0mm}
|
||||
% \setlength{\labelwidth}{0mm}
|
||||
% \setlength{\topsep}{0mm}
|
||||
}}{\end{list}}
|
||||
|
||||
|
||||
\newcommand{\workingnote}[1]{} % The version that hides the note.
|
||||
%\newcommand{\workingnote}[1]{(**#1)} % The version that makes the note visible.
|
||||
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Design challenges and social factors in deploying low-latency anonymity}
|
||||
% Could still use a better title -PFS
|
||||
|
||||
\author{Roger Dingledine\inst{1} \and
|
||||
Nick Mathewson\inst{1} \and
|
||||
Paul Syverson\inst{2}}
|
||||
\institute{The Tor Project \email{<\{arma,nickm\}@torproject.org>} \and
|
||||
Naval Research Laboratory \email{<syverson@itd.nrl.navy.mil>}}
|
||||
|
||||
\maketitle
|
||||
\pagestyle{plain}
|
||||
|
||||
\begin{abstract}
|
||||
There are many unexpected or unexpectedly difficult obstacles to
|
||||
deploying anonymous communications. We describe Tor (\emph{the}
|
||||
onion routing), how to use it, our design philosophy, and some of
|
||||
the challenges that we have faced and continue to face in building,
|
||||
deploying, and sustaining a scalable, distributed, low-latency
|
||||
anonymity network.
|
||||
\end{abstract}
|
||||
|
||||
\section{Introduction}
|
||||
This article describes Tor, a widely-used low-latency general-purpose
|
||||
anonymous communication system, and discusses some unexpected
|
||||
challenges arising from our experiences deploying Tor. We will tell
|
||||
you how to use it, who uses it, how it works, why we designed it the
|
||||
way we did, and why this makes it usable and stable.
|
||||
|
||||
Tor is an overlay network for anonymizing TCP streams over the
|
||||
Internet~\cite{tor-design}. Tor works on the real-world Internet,
|
||||
requires no special privileges or kernel modifications, requires
|
||||
little synchronization or coordination between nodes, and provides a
|
||||
reasonable trade-off between anonymity, usability, and efficiency.
|
||||
|
||||
Since deployment in October 2003 the public Tor network has grown to
|
||||
about a thousand volunteer-operated nodes worldwide and over 110
|
||||
megabytes average traffic per second from hundreds of thousands of
|
||||
concurrent users.
|
||||
|
||||
\section{Tor Design and Design Philosophy: Distributed Trust and Usability}
|
||||
|
||||
Tor enables users to connect to Internet sites without revealing their
|
||||
logical or physical locations to those sites or to observers. It
|
||||
enables hosts to be publicly accessible yet have similar protection
|
||||
against location through its \emph{location-hidden services}.
|
||||
|
||||
To connect to a remote server via Tor the client software first learns
|
||||
a %signed
|
||||
list of Tor nodes from several central \emph{directory servers} via a
|
||||
voting protocol (to avoid dependence on or complete trust in any one
|
||||
of these servers). It then incrementally creates a private pathway or
|
||||
\emph{circuit} across the network. This circuit consists of
|
||||
encrypted connections through authenticated Tor nodes
|
||||
whose public keys were obtained from the directory servers. The client
|
||||
software negotiates a separate set of encryption keys for each hop along the
|
||||
circuit. The nodes in the circuit are chosen at random by the client
|
||||
subject to a preference for higher performing nodes to allocate
|
||||
resources effectively and with a client-chosen preferred set of first
|
||||
nodes called \emph{entry guards} to complicate profiling attacks by
|
||||
internal adversaries~\cite{hs-attack}.
|
||||
The circuit is extended one node at a time, tunneling extensions
|
||||
through already established portions of the circuit, and each node
|
||||
along the way knows only the immediately previous and following nodes
|
||||
in the circuit, so no individual Tor node knows the complete path that
|
||||
each fixed-sized data packet (or \emph{cell}) will take. Thus,
|
||||
neither an eavesdropper nor a compromised node can see both the
|
||||
connection's source and destination. Later requests use a new
|
||||
circuit to complicate long-term linkability between different actions
|
||||
by a single user.
|
||||
|
||||
Tor attempts to anonymize the transport layer, not the application
|
||||
layer. Thus, applications such as SSH can provide
|
||||
authenticated communication that is hidden by Tor from outside observers.
|
||||
When anonymity from communication partners is desired,
|
||||
application-level protocols that transmit identifying
|
||||
information need additional scrubbing proxies, such as
|
||||
Privoxy~\cite{privoxy} for HTTP\@. Furthermore, Tor does not relay
|
||||
arbitrary IP packets; it only anonymizes TCP streams and DNS requests.
|
||||
|
||||
Tor, the third generation of deployed onion-routing
|
||||
designs~\cite{or-ih96,or-jsac98,tor-design}, was researched, developed,
|
||||
and deployed by the Naval Research Laboratory and the Free Haven
|
||||
Project under ONR and DARPA funding for secure government
|
||||
communications. In 2005, continuing work by Free Haven was funded by
|
||||
the Electronic Frontier Foundation for maintaining civil liberties of
|
||||
ordinary citizens online. In 2006, The Tor Project incorporated as a
|
||||
non-profit and has received continued funding from the Omidyar Network,
|
||||
the U.S. International Broadcasting Bureau, and other groups to combat
|
||||
blocking and censorship on the Internet. This diversity of funding fits
|
||||
Tor's overall philosophy: a wide variety of interests helps maintain
|
||||
both the stability and the security of the network.
|
||||
|
||||
Usability is also a central goal. Downloading and installing Tor is
|
||||
easy. Simply go to\\
|
||||
http://www.torproject.org/ and download. Tor comes with install
|
||||
wizards and a GUI for major operating systems: GNU/Linux, OS X, and
|
||||
Windows. It also runs on various flavors of BSD and UNIX\@. Basic
|
||||
instructions, documentation, FAQs, etc.\ are available in many
|
||||
languages. The Tor GUI Vidalia makes server configuration easy, e.g.,
|
||||
choosing how much bandwidth to allocate to Tor, exit policy choices,
|
||||
etc. And, the GUI Torbutton allows Firefox users a one-click toggle of
|
||||
whether browsing goes through Tor or not. Tor is easily configured by
|
||||
a site administrator to run at either individual desktops or just at a
|
||||
site firewall or combinations of these.
|
||||
|
||||
The ideal Tor network would be practical, useful and anonymous. When
|
||||
trade-offs arise between these properties, Tor's research strategy has
|
||||
been to remain useful enough to attract many users, and practical
|
||||
enough to support them. Only subject to these constraints do we try
|
||||
to maximize anonymity. Tor thus differs from other deployed systems
|
||||
for traffic analysis resistance in its security and flexibility. Mix
|
||||
networks such as
|
||||
% Mixmaster~\cite{mixmaster-spec} or its successor
|
||||
Mixminion~\cite{minion-design} gain the highest degrees of practical
|
||||
anonymity at the expense of introducing highly variable delays, making
|
||||
them unsuitable for applications such as web browsing. Commercial
|
||||
single-hop proxies~\cite{anonymizer} can provide good performance, but
|
||||
a single-point compromise can expose all users' traffic, and a
|
||||
single-point eavesdropper can perform traffic analysis on the entire
|
||||
network. Also, their proprietary implementations place any
|
||||
infrastructure that depends on these single-hop solutions at the mercy
|
||||
of their providers' financial health as well as network security.
|
||||
There are numerous other designs for distributed anonymous low-latency
|
||||
communication~\cite{crowds-tissec,web-mix,freedom21-security,i2p,tarzan:ccs02,morphmix:fc04}.
|
||||
Some have been deployed or even commercialized; some exist only on
|
||||
paper. Though each has something unique to offer, we feel Tor has
|
||||
advantages over each of them that make it a superior choice for most
|
||||
users and applications. For example, unlike purely P2P designs we
|
||||
neither limit ordinary users to content and services available only
|
||||
within our network nor require them to take on responsibility for
|
||||
connections outside the network, unless they separately choose to run
|
||||
server nodes. Nonetheless because we support low-latency interactive
|
||||
communications, end-to-end \emph{traffic correlation}
|
||||
attacks~\cite{danezis:pet2004,defensive-dropping,SS03,hs-attack,bauer:tr2007}
|
||||
allow an attacker who can observe both ends of a communication to
|
||||
correlate packet timing and volume, quickly linking the initiator to
|
||||
her destination.
|
||||
|
||||
|
||||
Our defense lies in having a diverse enough set of nodes to prevent
|
||||
most real-world adversaries from being in the right places to attack
|
||||
users, by distributing each transaction over several nodes in the
|
||||
network. This ``distributed trust'' approach means the Tor network
|
||||
can be safely operated and used by a wide variety of mutually
|
||||
distrustful users, providing sustainability and security.
|
||||
|
||||
The Tor network has a broad range of users, making it difficult for
|
||||
eavesdroppers to track them or profile interests. These include
|
||||
ordinary citizens concerned about their privacy, corporations who
|
||||
don't want to reveal information to their competitors, and law
|
||||
enforcement and government intelligence agencies who need to do
|
||||
operations on the Internet without being noticed. Naturally,
|
||||
organizations will not want to depend on others for their security.
|
||||
If most participating providers are reliable, Tor tolerates some
|
||||
hostile infiltration of the network.
|
||||
|
||||
This distribution of trust is central to the Tor philosophy and
|
||||
pervades Tor at all levels: Onion routing has been open source since
|
||||
the mid-nineties (mistrusting users can inspect the code themselves);
|
||||
Tor is free software (anyone could take up the development of Tor from
|
||||
the current team); anyone can use Tor without license or charge (which
|
||||
encourages a broad user base with diverse interests); Tor is designed to be
|
||||
usable (also promotes a large, diverse user base) and configurable (so
|
||||
users can easily set up and run server nodes); the Tor
|
||||
infrastructure is run by volunteers (it is not dependent on the
|
||||
economic viability or business strategy of any company) who are
|
||||
scattered around the globe (not completely under the jurisdiction of
|
||||
any single country); ongoing development and deployment has been
|
||||
funded by diverse sources (development does not fully depend on
|
||||
funding from any one source or even funding for any one primary
|
||||
purpose or sources in any one jurisdiction). All of these contribute
|
||||
to Tor's resilience and sustainability.
|
||||
|
||||
|
||||
\section{Social challenges}
|
||||
|
||||
Many of the issues the Tor project needs to address extend beyond
|
||||
system design and technology development. In particular, the Tor
|
||||
project's \emph{image} with respect to its users and the rest of the
|
||||
Internet impacts the security it can provide. With this image issue
|
||||
in mind, this section discusses the Tor user base and Tor's
|
||||
interaction with other services on the Internet.
|
||||
|
||||
\subsection{Communicating security}
|
||||
|
||||
Usability for anonymity systems contributes to their security, because
|
||||
usability affects the possible anonymity set~\cite{econymics,back01}.
|
||||
Conversely, an unusable system attracts few users and thus can't
|
||||
provide much anonymity.
|
||||
|
||||
This phenomenon has a second-order effect: knowing this, users should
|
||||
choose which anonymity system to use based in part on how usable and
|
||||
secure \emph{others} will find it, in order to get the protection of a
|
||||
larger anonymity set. Thus we might supplement the adage ``usability
|
||||
is a security parameter''~\cite{back01} with a new one: ``perceived
|
||||
usability is a security parameter.''~\cite{usability-network-effect}.
|
||||
|
||||
|
||||
|
||||
\subsection{Reputability and perceived social value}
|
||||
Another factor impacting the network's security is its reputability,
|
||||
the perception of its social value based on its current user base. If
|
||||
Alice is the only user who has ever downloaded the software, it might
|
||||
be socially accepted, but she's not getting much anonymity. Add a
|
||||
thousand activists, and she's anonymous, but everyone thinks she's an
|
||||
activist too. Add a thousand diverse citizens (cancer survivors,
|
||||
people concerned about identity theft, law enforcement agents, and so
|
||||
on) and now she's harder to profile.
|
||||
|
||||
Furthermore, the network's reputability affects its operator base:
|
||||
more people are willing to run a service if they believe it will be
|
||||
used by human rights workers than if they believe it will be used
|
||||
exclusively for disreputable ends. This effect becomes stronger if
|
||||
node operators themselves think they will be associated with their
|
||||
users' ends.
|
||||
|
||||
So the more cancer survivors on Tor, the better for the human rights
|
||||
activists. The more malicious hackers, the worse for the normal
|
||||
users. Thus, reputability is an anonymity issue for two
|
||||
reasons. First, it impacts the sustainability of the network: a
|
||||
network that's always about to be shut down has difficulty attracting
|
||||
and keeping adequate nodes. Second, a disreputable network is more
|
||||
vulnerable to legal and political attacks, since it will attract fewer
|
||||
supporters.
|
||||
|
||||
Reputability becomes even more tricky in the case of privacy networks,
|
||||
since the good uses of the network (such as publishing by journalists
|
||||
in dangerous countries, protecting road warriors from profiling and
|
||||
potential physical harm, tracking of criminals by law enforcement,
|
||||
protecting corporate research interests, etc.) are typically kept private,
|
||||
whereas network abuses or other problems tend to be more widely
|
||||
publicized.
|
||||
|
||||
|
||||
\subsection{Abuse}
|
||||
\label{subsec:tor-and-blacklists}
|
||||
|
||||
For someone willing to be antisocial or even break the law, Tor is
|
||||
usually a poor choice to hide bad behavior. For example, Tor nodes are
|
||||
publicly identified, unlike the million-node botnets that are now
|
||||
common on the Internet. Nonetheless, we always expected that,
|
||||
alongside legitimate users, Tor would also attract troublemakers who
|
||||
exploit Tor to abuse services on the Internet with vandalism, rude
|
||||
mail, and so on. \emph{Exit policies} have allowed individual nodes
|
||||
to block access to specific IP/port ranges. This approach aims to
|
||||
make operators more willing to run Tor by allowing them to prevent
|
||||
their nodes from being used for abusing particular services. For
|
||||
example, by default Tor nodes block SMTP (port 25), to avoid the issue
|
||||
of spam.
|
||||
|
||||
Exit policies are useful but insufficient: if not all nodes block a
|
||||
given service, that service may try to block Tor instead. While being
|
||||
blockable is important to being good netizens, we would like to
|
||||
encourage services to allow anonymous access. Services should not need
|
||||
to decide between blocking legitimate anonymous use and allowing
|
||||
unlimited abuse. Nonetheless, blocking IP addresses is a
|
||||
course-grained solution~\cite{netauth}: entire apartment buildings,
|
||||
campuses, and even countries sometimes share a single IP address.
|
||||
Also, whether intended or not, such blocking supports repression of
|
||||
free speech. In many locations where Internet access of various kinds
|
||||
is censored or even punished by imprisonment, Tor is a path both to
|
||||
the outside world and to others inside. Blocking posts from Tor makes
|
||||
the job of censoring authorities easier. This is a loss for both Tor
|
||||
and services that block, such as Wikipedia: we don't want to compete
|
||||
for (or divvy up) the NAT-protected entities of the world. This is
|
||||
also unfortunate because there are relatively simple technical
|
||||
solutions~\cite{nym}. Various schemes for escrowing anonymous posts
|
||||
until they are reviewed by editors would both prevent abuse and remove
|
||||
incentives for attempts to abuse. Further, pseudonymous reputation
|
||||
tracking of posters through Tor would allow those who establish
|
||||
adequate reputation to post without escrow~\cite{nym,nymble}.
|
||||
|
||||
We stress that as far as we can tell, most Tor uses are not
|
||||
abusive. Most services have not complained, and others are actively
|
||||
working to find ways besides banning to cope with the abuse. For
|
||||
example, the Freenode IRC network had a problem with a coordinated
|
||||
group of abusers joining channels and subtly taking over the
|
||||
conversation; but when they labelled all users coming from Tor IP
|
||||
addresses as ``anonymous users,'' removing the ability of the abusers
|
||||
to blend in, the abusers stopped using Tor. This is an illustration of
|
||||
how simple
|
||||
technical mechanisms can remove the ability to abuse anonymously
|
||||
without undermining the ability to communicate anonymously and can
|
||||
thus remove the incentive to attempt abusing in this way.
|
||||
|
||||
|
||||
|
||||
\section{The Future}
|
||||
\label{sec:conclusion}
|
||||
|
||||
Tor is the largest and most diverse low-latency anonymity network
|
||||
available, but we are still in the early stages. Several major
|
||||
questions remain.
|
||||
|
||||
First, will our volunteer-based approach to sustainability continue to
|
||||
work as well in the long term as it has the first several years?
|
||||
Besides node operation, Tor research, deployment, maintainance, and
|
||||
development is increasingly done by volunteers: package maintenance
|
||||
for various OSes, document translation, GUI design and implementation,
|
||||
live CDs, specification of new design changes, etc.\
|
||||
%
|
||||
Second, Tor is only one of many components that preserve privacy
|
||||
online. For applications where it is desirable to keep identifying
|
||||
information out of application traffic, someone must build more and
|
||||
better protocol-aware proxies that are usable by ordinary people.
|
||||
%
|
||||
Third, we need to maintain a reputation for social good, and learn how to
|
||||
coexist with the variety of Internet services and their established
|
||||
authentication mechanisms. We can't just keep escalating the blacklist
|
||||
standoff forever.
|
||||
%
|
||||
Fourth, the current Tor architecture hardly scales even to handle
|
||||
current user demand. We must deploy designs and incentives to further
|
||||
encourage clients to relay traffic too, without thereby trading away
|
||||
too much anonymity or other properties.
|
||||
|
||||
These are difficult and open questions. Yet choosing not to solve them
|
||||
means leaving most users to a less secure network or no anonymizing
|
||||
network at all.\\
|
||||
|
||||
\noindent{\bf Acknowledgment:} Thanks to Matt Edman for many
|
||||
helpful comments on a draft of this article.
|
||||
\bibliographystyle{plain} \bibliography{tor-design}
|
||||
|
||||
\end{document}
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@ -1,96 +0,0 @@
|
||||
% usenix-2e.sty - to be used with latex2e (the new one) for USENIX.
|
||||
% To use this style file, do this:
|
||||
%
|
||||
% \documentclass[twocolumn]{article}
|
||||
% \usepackage{usenix-2e}
|
||||
% and put {\rm ....} around the author names.
|
||||
%
|
||||
% The following definitions are modifications of standard article.sty
|
||||
% definitions, arranged to do a better job of matching the USENIX
|
||||
% guidelines.
|
||||
% It will automatically select two-column mode and the Times-Roman
|
||||
% font.
|
||||
|
||||
%
|
||||
% USENIX papers are two-column.
|
||||
% Times-Roman font is nice if you can get it (requires NFSS,
|
||||
% which is in latex2e.
|
||||
|
||||
\if@twocolumn\else\input twocolumn.sty\fi
|
||||
\usepackage{times}
|
||||
|
||||
%
|
||||
% USENIX wants margins of: 7/8" side, 1" bottom, and 3/4" top.
|
||||
% 0.25" gutter between columns.
|
||||
% Gives active areas of 6.75" x 9.25"
|
||||
%
|
||||
\setlength{\textheight}{9.0in}
|
||||
\setlength{\columnsep}{0.25in}
|
||||
%%\setlength{\textwidth}{6.75in}
|
||||
\setlength{\textwidth}{7.00in}
|
||||
%\setlength{\footheight}{0.0in}
|
||||
\setlength{\topmargin}{-0.25in}
|
||||
\setlength{\headheight}{0.0in}
|
||||
\setlength{\headsep}{0.0in}
|
||||
\setlength{\evensidemargin}{-0.125in}
|
||||
\setlength{\oddsidemargin}{-0.125in}
|
||||
|
||||
%
|
||||
% Usenix wants no page numbers for submitted papers, so that they can
|
||||
% number them themselves.
|
||||
%
|
||||
\pagestyle{empty}
|
||||
|
||||
%
|
||||
% Usenix titles are in 14-point bold type, with no date, and with no
|
||||
% change in the empty page headers. The whol author section is 12 point
|
||||
% italic--- you must use {\rm } around the actual author names to get
|
||||
% them in roman.
|
||||
%
|
||||
\def\maketitle{\par
|
||||
\begingroup
|
||||
\renewcommand\thefootnote{\fnsymbol{footnote}}%
|
||||
\def\@makefnmark{\hbox to\z@{$\m@th^{\@thefnmark}$\hss}}%
|
||||
\long\def\@makefntext##1{\parindent 1em\noindent
|
||||
\hbox to1.8em{\hss$\m@th^{\@thefnmark}$}##1}%
|
||||
\if@twocolumn
|
||||
\twocolumn[\@maketitle]%
|
||||
\else \newpage
|
||||
\global\@topnum\z@
|
||||
\@maketitle \fi\@thanks
|
||||
\endgroup
|
||||
\setcounter{footnote}{0}%
|
||||
\let\maketitle\relax
|
||||
\let\@maketitle\relax
|
||||
\gdef\@thanks{}\gdef\@author{}\gdef\@title{}\let\thanks\relax}
|
||||
|
||||
\def\@maketitle{\newpage
|
||||
\vbox to 2.5in{
|
||||
\vspace*{\fill}
|
||||
\vskip 2em
|
||||
\begin{center}%
|
||||
{\Large\bf \@title \par}%
|
||||
\vskip 0.375in minus 0.300in
|
||||
{\large\it
|
||||
\lineskip .5em
|
||||
\begin{tabular}[t]{c}\@author
|
||||
\end{tabular}\par}%
|
||||
\end{center}%
|
||||
\par
|
||||
\vspace*{\fill}
|
||||
% \vskip 1.5em
|
||||
}
|
||||
}
|
||||
|
||||
%
|
||||
% The abstract is preceded by a 12-pt bold centered heading
|
||||
\def\abstract{\begin{center}%
|
||||
{\large\bf \abstractname\vspace{-.5em}\vspace{\z@}}%
|
||||
\end{center}}
|
||||
\def\endabstract{}
|
||||
|
||||
%
|
||||
% Main section titles are 12-pt bold. Others can be same or smaller.
|
||||
%
|
||||
\def\section{\@startsection {section}{1}{\z@}{-3.5ex plus-1ex minus
|
||||
-.2ex}{2.3ex plus.2ex}{\reset@font\large\bf}}
|
||||
@ -1,7 +0,0 @@
|
||||
% Created by Anil Somayaji
|
||||
|
||||
\ProvidesClass{usenixsubmit}
|
||||
\LoadClass[11pt,letterpaper]{article}
|
||||
\usepackage{times}
|
||||
\usepackage[margin=1in]{geometry}
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -1,690 +0,0 @@
|
||||
\documentclass{article}
|
||||
|
||||
\usepackage{url}
|
||||
|
||||
\newenvironment{tightlist}{\begin{list}{$\bullet$}{
|
||||
\setlength{\itemsep}{0mm}
|
||||
\setlength{\parsep}{0mm}
|
||||
% \setlength{\labelsep}{0mm}
|
||||
% \setlength{\labelwidth}{0mm}
|
||||
% \setlength{\topsep}{0mm}
|
||||
}}{\end{list}}
|
||||
\newcommand{\tmp}[1]{{\bf #1} [......] \\}
|
||||
\newcommand{\plan}[1]{ {\bf (#1)}}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Tor Development Roadmap: Wishlist for Nov 2006--Dec 2007}
|
||||
\author{Roger Dingledine \and Nick Mathewson \and Shava Nerad}
|
||||
|
||||
\maketitle
|
||||
\pagestyle{plain}
|
||||
|
||||
% TO DO:
|
||||
% add cites
|
||||
% add time estimates
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
%Hi, Roger! Hi, Shava. This paragraph should get deleted soon. Right now,
|
||||
%this document goes into about as much detail as I'd like to go into for a
|
||||
%technical audience, since that's the audience I know best. It doesn't have
|
||||
%time estimates everywhere. It isn't well prioritized, and it doesn't
|
||||
%distinguish well between things that need lots of research and things that
|
||||
%don't. The breakdowns don't all make sense. There are lots of things where
|
||||
%I don't make it clear how they fit into larger goals, and lots of larger
|
||||
%goals that don't break down into little things. It isn't all stuff we can do
|
||||
%for sure, and it isn't even all stuff we can do for sure in 2007. The
|
||||
%tmp\{\} macro indicates stuff I haven't said enough about. That said, here
|
||||
%plangoes...
|
||||
|
||||
Tor (the software) and Tor (the overall software/network/support/document
|
||||
suite) are now experiencing all the crises of success. Over the next year,
|
||||
we're probably going to grow more in terms of users, developers, and funding
|
||||
than before. This gives us the opportunity to perform long-neglected
|
||||
maintenance tasks.
|
||||
|
||||
\section{Code and design infrastructure}
|
||||
|
||||
\subsection{Protocol revision}
|
||||
To maintain backward compatibility, we've postponed major protocol
|
||||
changes and redesigns for a long time. Because of this, there are a number
|
||||
of sensible revisions we've been putting off until we could deploy several of
|
||||
them at once. To do each of these, we first need to discuss design
|
||||
alternatives with other cryptographers and outside collaborators to
|
||||
make sure that our choices are secure.
|
||||
|
||||
First of all, our protocol needs better {\bf versioning support} so that we
|
||||
can make backward-incompatible changes to our core protocol. There are
|
||||
difficult anonymity issues here, since many naive designs would make it easy
|
||||
to tell clients apart (and then track them) based on their supported versions.
|
||||
|
||||
With protocol versioning support would come the ability to {\bf future-proof
|
||||
our ciphersuites}. For example, not only our OR protocol, but also our
|
||||
directory protocol, is pretty firmly tied to the SHA-1 hash function, which
|
||||
though not yet known to be insecure for our purposes, has begun to show
|
||||
its age. We should
|
||||
remove assumptions throughout our design based on the assumption that public
|
||||
keys, secret keys, or digests will remain any particular size indefinitely.
|
||||
|
||||
Our OR {\bf authentication protocol}, though provably
|
||||
secure\cite{tap:pet2006}, relies more on particular aspects of RSA and our
|
||||
implementation thereof than we had initially believed. To future-proof
|
||||
against changes, we should replace it with a less delicate approach.
|
||||
|
||||
\plan{For all the above: 2 person-months to specify, spread over several
|
||||
months with time for interaction with external participants. One
|
||||
person-month to implement. Start specifying in early 2007.}
|
||||
|
||||
We might design a {\bf stream migration} feature so that streams tunneled
|
||||
over Tor could be more resilient to dropped connections and changed IPs.
|
||||
\plan{Not in 2007.}
|
||||
|
||||
A new protocol could support {\bf multiple cell sizes}. Right now, all data
|
||||
passes through the Tor network divided into 512-byte cells. This is
|
||||
efficient for high-bandwidth protocols, but inefficient for protocols
|
||||
like SSH or AIM that send information in small chunks. Of course, we need to
|
||||
investigate the extent to which multiple sizes could make it easier for an
|
||||
adversary to fingerprint a traffic pattern. \plan{Not in 2007.}
|
||||
|
||||
As a part of our design, we should investigate possible {\bf cipher modes}
|
||||
other than counter mode. For example, a mode with built-in integrity
|
||||
checking, error propagation, and random access could simplify our protocol
|
||||
significantly. Sadly, many of these are patented and unavailable for us.
|
||||
\plan{Not in 2007.}
|
||||
|
||||
\subsection{Scalability}
|
||||
|
||||
\subsubsection{Improved directory efficiency}
|
||||
Right now, clients download a statement of the {\bf network status} made by
|
||||
each directory authority. We could reduce network bandwidth significantly by
|
||||
having the authorities jointly sign a statement reflecting their vote on the
|
||||
current network status. This would save clients up to 160K per hour, and
|
||||
make their view of the network more uniform. Of course, we'd need to make
|
||||
sure the voting process was secure and resilient to failures in the
|
||||
network.\plan{Must do; specify in 2006. 2 weeks to specify, 3-4 weeks to
|
||||
implement.}
|
||||
|
||||
We should {\bf shorten router descriptors}, since the current format includes
|
||||
a great deal of information that's only of interest to the directory
|
||||
authorities, and not of interest to clients. We can do this by having each
|
||||
router upload a short-form and a long-form signed descriptor, and having
|
||||
clients download only the short form. Even a naive version of this would
|
||||
save about 40\% of the bandwidth currently spent by clients downloading
|
||||
descriptors.\plan{Must do; specify in 2006. 3-4 weeks.}
|
||||
|
||||
We should {\bf have routers upload their descriptors even less often}, so
|
||||
that clients do not need to download replacements every 18 hours whether any
|
||||
information has changed or not. (As of Tor 0.1.2.3-alpha, clients tolerate
|
||||
routers that don't upload often, but routers still upload at least every 18
|
||||
hours to support older clients.) \plan{Must do, but not until 0.1.1.x is
|
||||
deprecated in mid 2007. 1 week.}
|
||||
|
||||
\subsubsection{Non-clique topology}
|
||||
Our current network design achieves a certain amount of its anonymity by
|
||||
making clients act like each other through the simple expedient of making
|
||||
sure that all clients know all servers, and that any server can talk to any
|
||||
other server. But as the number of servers increases to serve an
|
||||
ever-greater number of clients, these assumptions become impractical.
|
||||
|
||||
At worst, if these scalability issues become troubling before a solution is
|
||||
found, we can design and build a solution to {\bf split the network into
|
||||
multiple slices} until a better solution comes along. This is not ideal,
|
||||
since rather than looking like all other users from a point of view of path
|
||||
selection, users would ``only'' look like 200,000--300,000 other
|
||||
users.\plan{Not unless needed.}
|
||||
|
||||
We are in the process of designing {\bf improved schemes for network
|
||||
scalability}. Some approaches focus on limiting what an adversary can know
|
||||
about what a user knows; others focus on reducing the extent to which an
|
||||
adversary can exploit this knowledge. These are currently in their infancy,
|
||||
and will probably not be needed in 2007, but they must be designed in 2007 if
|
||||
they are to be deployed in 2008.\plan{Design in 2007; unknown difficulty.
|
||||
Write a paper.}
|
||||
|
||||
\subsubsection{Relay incentives}
|
||||
To support more users on the network, we need to get more servers. So far,
|
||||
we've relied on volunteerism to attract server operators, and so far it's
|
||||
served us well. But in the long run, we need to {\bf design incentives for
|
||||
users to run servers} and relay traffic for others. Most obviously, we
|
||||
could try to build the network so that servers offered improved service for
|
||||
other servers, but we would need to do so without weakening anonymity and
|
||||
making it obvious which connections originate from users running servers. We
|
||||
have some preliminary designs~\cite{incentives-txt,tor-challenges},
|
||||
but need to perform
|
||||
some more research to make sure they would be safe and effective.\plan{Write
|
||||
a draft paper; 2 person-months.}
|
||||
|
||||
\subsection{Portability}
|
||||
Our {\bf Windows implementation}, though much improved, continues to lag
|
||||
behind Unix and Mac OS X, especially when running as a server. We hope to
|
||||
merge promising patches from Mike Chiussi to address this point, and bring
|
||||
Windows performance on par with other platforms.\plan{Do in 2007; 1.5 months
|
||||
to integrate not counting Mike's work.}
|
||||
|
||||
We should have {\bf better support for portable devices}, including modes of
|
||||
operation that require less RAM, and that write to disk less frequently (to
|
||||
avoid wearing out flash RAM).\plan{Optional; 2 weeks.}
|
||||
|
||||
We should {\bf stop using socketpair on Windows}; instead, we can use
|
||||
in-memory structures to communicate between cpuworkers and the main thread,
|
||||
and between connections.\plan{Optional; 1 week.}
|
||||
|
||||
\subsection{Performance: resource usage}
|
||||
We've been working on {\bf using less RAM}, especially on servers. This has
|
||||
paid off a lot for directory caches in the 0.1.2, which in some cases are
|
||||
using 90\% less memory than they used to require. But we can do better,
|
||||
especially in the area around our buffer management algorithms, by using an
|
||||
approach more like the BSD and Linux kernels use instead of our current ring
|
||||
buffer approach. (For OR connections, we can just use queues of cell-sized
|
||||
chunks produced with a specialized allocator.) This could potentially save
|
||||
around 25 to 50\% of the memory currently allocated for network buffers, and
|
||||
make Tor a more attractive proposition for restricted-memory environments
|
||||
like old computers, mobile devices, and the like.\plan{Do in 2007; 2-3 weeks
|
||||
plus one week measurement.}
|
||||
|
||||
We should improve our {\bf bandwidth limiting}. The current system has been
|
||||
crucial in making users willing to run servers: nobody is willing to run a
|
||||
server if it might use an unbounded amount of bandwidth, especially if they
|
||||
are charged for their usage. We can make our system better by letting users
|
||||
configure bandwidth limits independently for their own traffic and traffic
|
||||
relayed for others; and by adding write limits for users running directory
|
||||
servers.\plan{Do in 2006; 2-3 weeks.}
|
||||
|
||||
On many hosts, sockets are still in short supply, and will be until we can
|
||||
migrate our protocol to UDP. We can {\bf use fewer sockets} by making our
|
||||
self-to-self connections happen internally to the code rather than involving
|
||||
the operating system's socket implementation.\plan{Optional; 1 week.}
|
||||
|
||||
\subsection{Performance: network usage}
|
||||
We know too little about how well our current path
|
||||
selection algorithms actually spread traffic around the network in practice.
|
||||
We should {\bf research the efficacy of our traffic allocation} and either
|
||||
assure ourselves that it is close enough to optimal as to need no improvement
|
||||
(unlikely) or {\bf identify ways to improve network usage}, and get more
|
||||
users' traffic delivered faster. Performing this research will require
|
||||
careful thought about anonymity implications.
|
||||
|
||||
We should also {\bf examine the efficacy of our congestion control
|
||||
algorithm}, and see whether we can improve client performance in the
|
||||
presence of a congested network through dynamic `sendme' window sizes or
|
||||
other means. This will have anonymity implications too if we aren't careful.
|
||||
|
||||
\plan{For both of the above: research, design and write
|
||||
a measurement tool in 2007: 1 month. See if we can interest a graduate
|
||||
student.}
|
||||
|
||||
We should work on making Tor's cell-based protocol perform better on
|
||||
networks with low bandwidth
|
||||
and high packet loss.\plan{Do in 2007 if we're funded to do it; 4-6 weeks.}
|
||||
|
||||
\subsection{Performance scenario: one Tor client, many users}
|
||||
We should {\bf improve Tor's performance when a single Tor handles many
|
||||
clients}. Many organizations want to manage a single Tor client on their
|
||||
firewall for many users, rather than having each user install a separate
|
||||
Tor client. We haven't optimized for this scenario, and it is likely that
|
||||
there are some code paths in the current implementation that become
|
||||
inefficient when a single Tor is servicing hundreds or thousands of client
|
||||
connections. (Additionally, it is likely that such clients have interesting
|
||||
anonymity requirements the we should investigate.) We should profile Tor
|
||||
under appropriate loads, identify bottlenecks, and fix them.\plan{Do in 2007
|
||||
if we're funded to do it; 4-8 weeks.}
|
||||
|
||||
\subsection{Tor servers on asymmetric bandwidth}
|
||||
|
||||
Tor should work better on servers that have asymmetric connections like cable
|
||||
or DSL. Because Tor has separate TCP connections between each
|
||||
hop, if the incoming bytes are arriving just fine and the outgoing bytes are
|
||||
all getting dropped on the floor, the TCP push-back mechanisms don't really
|
||||
transmit this information back to the incoming streams.\plan{Do in 2007 since
|
||||
related to bandwidth limiting. 3-4 weeks.}
|
||||
|
||||
\subsection{Running Tor as both client and server}
|
||||
|
||||
Many performance tradeoffs and balances that might need more attention.
|
||||
We first need to track and fix whatever bottlenecks emerge; but we also
|
||||
need to invent good algorithms for prioritizing the client's traffic
|
||||
without starving the server's traffic too much.\plan{No idea; try
|
||||
profiling and improving things in 2007.}
|
||||
|
||||
\subsection{Protocol redesign for UDP}
|
||||
Tor has relayed only TCP traffic since its first versions, and has used
|
||||
TLS-over-TCP to do so. This approach has proved reliable and flexible, but
|
||||
in the long term we will need to allow UDP traffic on the network, and switch
|
||||
some or all of the network to using a UDP transport. {\bf Supporting UDP
|
||||
traffic} will make Tor more suitable for protocols that require UDP, such
|
||||
as many VOIP protocols. {\bf Using a UDP transport} could greatly reduce
|
||||
resource limitations on servers, and make the network far less interruptible
|
||||
by lossy connections. Either of these protocol changes would require a great
|
||||
deal of design work, however. We hope to be able to enlist the aid of a few
|
||||
talented graduate students to assist with the initial design and
|
||||
specification, but the actual implementation will require significant testing
|
||||
of different reliable transport approaches.\plan{Maybe do a design in 2007 if
|
||||
we find an interested academic. Ian or Ben L might be good partners here.}
|
||||
|
||||
\section{Blocking resistance}
|
||||
|
||||
\subsection{Design for blocking resistance}
|
||||
We have written a design document explaining our general approach to blocking
|
||||
resistance. We should workshop it with other experts in the field to get
|
||||
their ideas about how we can improve Tor's efficacy as an anti-censorship
|
||||
tool.
|
||||
|
||||
\subsection{Implementation: client-side and bridges-side}
|
||||
|
||||
Our anticensorship design calls for some nodes to act as ``bridges''
|
||||
that are outside a national firewall, and others inside the firewall to
|
||||
act as pure clients. This part of the design is quite clear-cut; we're
|
||||
probably ready to begin implementing it. To {\bf implement bridges}, we
|
||||
need to have servers publish themselves as limited-availability relays
|
||||
to a special bridge authority if they judge they'd make good servers.
|
||||
We will also need to help provide documentation for port forwarding,
|
||||
and an easy configuration tool for running as a bridge.
|
||||
|
||||
To {\bf implement clients}, we need to provide a flexible interface to
|
||||
learn about bridges and to act on knowledge of bridges. We also need
|
||||
to teach them how to know to use bridges as their first hop, and how to
|
||||
fetch directory information from both classes of directory authority.
|
||||
|
||||
Clients also need to {\bf use the encrypted directory variant} added in Tor
|
||||
0.1.2.3-alpha. This will let them retrieve directory information over Tor
|
||||
once they've got their initial bridges. We may want to get the rest of the
|
||||
Tor user base to begin using this encrypted directory variant too, to
|
||||
provide cover.
|
||||
|
||||
Bridges will want to be able to {\bf listen on multiple addresses and ports}
|
||||
if they can, to give the adversary more ports to block.
|
||||
|
||||
\subsection{Research: anonymity implications from becoming a bridge}
|
||||
|
||||
\subsection{Implementation: bridge authority}
|
||||
|
||||
The design here is also reasonably clear-cut: we need to run some
|
||||
directory authorities with a slightly modified protocol that doesn't leak
|
||||
the entire list of bridges. Thus users can learn up-to-date information
|
||||
for bridges they already know about, but they can't learn about arbitrary
|
||||
new bridges.
|
||||
|
||||
\subsection{Normalizing the Tor protocol on the wire}
|
||||
Additionally, we should {\bf resist content-based filters}. Though an
|
||||
adversary can't see what users are saying, some aspects of our protocol are
|
||||
easy to fingerprint {\em as} Tor. We should correct this where possible.
|
||||
|
||||
Look like Firefox; or look like nothing?
|
||||
Future research: investigate timing similarities with other protocols.
|
||||
|
||||
\subsection{Access control for bridges}
|
||||
Design/impl: password-protecting bridges, in light of above.
|
||||
And/or more general access control.
|
||||
|
||||
\subsection{Research: scanning-resistance}
|
||||
|
||||
\subsection{Research/Design/Impl: how users discover bridges}
|
||||
Our design anticipates an arms race between discovery methods and censors.
|
||||
We need to begin the infrastructure on our side quickly, preferably in a
|
||||
flexible language like Python, so we can adapt quickly to censorship.
|
||||
|
||||
phase one: personal bridges
|
||||
phase two: families of personal bridges
|
||||
phase three: more structured social network
|
||||
phase four: bag of tricks
|
||||
Research: phase five...
|
||||
|
||||
Integration with Psiphon, etc?
|
||||
|
||||
\subsection{Document best practices for users}
|
||||
Document best practices for various activities common among
|
||||
blocked users (e.g. WordPress use).
|
||||
|
||||
\subsection{Research: how to know if a bridge has been blocked?}
|
||||
|
||||
\subsection{GeoIP maintenance, and "private" user statistics}
|
||||
How to know if the whole idea is working?
|
||||
|
||||
\subsection{Research: hiding whether the user is reading or publishing?}
|
||||
|
||||
\subsection{Research: how many bridges do you need to know to maintain
|
||||
reachability?}
|
||||
|
||||
\subsection{Resisting censorship of the Tor website, docs, and mirrors}
|
||||
|
||||
We should take some effort to consider {\bf initial distribution of Tor and
|
||||
related information} in countries where the Tor website and mirrors are
|
||||
censored. (Right now, most countries that block access to Tor block only the
|
||||
main website and leave mirrors and the network itself untouched.) Falling
|
||||
back on word-of-mouth is always a good last resort, but we should also take
|
||||
steps to make sure it's relatively easy for users to get ahold of a copy.
|
||||
|
||||
\section{Security}
|
||||
|
||||
\subsection{Security research projects}
|
||||
|
||||
We should investigate approaches with some promise to help Tor resist
|
||||
end-to-end traffic correlation attacks. It's an open research question
|
||||
whether (and to what extent) {\bf mixed-latency} networks, {\bf low-volume
|
||||
long-distance padding}, or other approaches can resist these attacks, which
|
||||
are currently some of the most effective against careful Tor users. We
|
||||
should research these questions and perform simulations to identify
|
||||
opportunities for strengthening our design without dropping performance to
|
||||
unacceptable levels. %Cite something
|
||||
\plan{Start doing this in 2007; write a paper. 8-16 weeks.}
|
||||
|
||||
We've got some preliminary results suggesting that {\bf a topology-aware
|
||||
routing algorithm}~\cite{feamster:wpes2004} could reduce Tor users'
|
||||
vulnerability against local or ISP-level adversaries, by ensuring that they
|
||||
are never in a position to watch both ends of a connection. We need to
|
||||
examine the effects of this approach in more detail and consider side-effects
|
||||
on anonymity against other kinds of adversaries. If the approach still looks
|
||||
promising, we should investigate ways for clients to implement it (or an
|
||||
approximation of it) without having to download routing tables for the whole
|
||||
Internet. \plan{Not in 2007 unless a graduate student wants to do it.}
|
||||
|
||||
%\tmp{defenses against end-to-end correlation} We don't expect any to work
|
||||
%right now, but it would be useful to learn that one did. Alternatively,
|
||||
%proving that one didn't would free up researchers in the field to go work on
|
||||
%other things.
|
||||
%
|
||||
% See above; I think I got this.
|
||||
|
||||
We should research the efficacy of {\bf website fingerprinting} attacks,
|
||||
wherein an adversary tries to match the distinctive traffic and timing
|
||||
pattern of the resources constituting a given website to the traffic pattern
|
||||
of a user's client. These attacks work great in simulations, but in
|
||||
practice we hear they don't work nearly as well. We should get some actual
|
||||
numbers to investigate the issue, and figure out what's going on. If we
|
||||
resist these attacks, or can improve our design to resist them, we should.
|
||||
% add cites
|
||||
\plan{Possibly part of end-to-end correlation paper. Otherwise, not in 2007
|
||||
unless a graduate student is interested.}
|
||||
|
||||
\subsection{Implementation security}
|
||||
Right now, each Tor node stores its keys unencrypted. We should {\bf encrypt
|
||||
more Tor keys} so that Tor authorities can require a startup password. We
|
||||
should look into adding intermediary medium-term ``signing keys'' between
|
||||
identity keys and onion keys, so that a password could be required to replace
|
||||
a signing key, but not to start Tor. This would improve Tor's long-term
|
||||
security, especially in its directory authority infrastructure.\plan{Design this
|
||||
as a part of the revised ``v2.1'' directory protocol; implement it in
|
||||
2007. 3-4 weeks.}
|
||||
|
||||
We should also {\bf mark RAM that holds key material as non-swappable} so
|
||||
that there is no risk of recovering key material from a hard disk
|
||||
compromise. This would require submitting patches upstream to OpenSSL, where
|
||||
support for marking memory as sensitive is currently in a very preliminary
|
||||
state.\plan{Nice to do, but not in immediate Tor scope.}
|
||||
|
||||
There are numerous tools for identifying trouble spots in code (such as
|
||||
Coverity or even VS2005's code analysis tool) and we should convince somebody
|
||||
to run some of them against the Tor codebase. Ideally, we could figure out a
|
||||
way to get our code checked periodically rather than just once.\plan{Almost
|
||||
no time once we talk somebody into it.}
|
||||
|
||||
We should try {\bf protocol fuzzing} to identify errors in our
|
||||
implementation.\plan{Not in 2007 unless we find a grad student or
|
||||
undergraduate who wants to try.}
|
||||
|
||||
Our guard nodes help prevent an attacker from being able to become a chosen
|
||||
client's entry point by having each client choose a few favorite entry points
|
||||
as ``guards'' and stick to them. We should implement a {\bf directory
|
||||
guards} feature to keep adversaries from enumerating Tor users by acting as
|
||||
a directory cache.\plan{Do in 2007; 2 weeks.}
|
||||
|
||||
\subsection{Detect corrupt exits and other servers}
|
||||
With the success of our network, we've attracted servers in many locations,
|
||||
operated by many kinds of people. Unfortunately, some of these locations
|
||||
have compromised or defective networks, and some of these people are
|
||||
untrustworthy or incompetent. Our current design relies on authority
|
||||
administrators to identify bad nodes and mark them as nonfunctioning. We
|
||||
should {\bf automate the process of identifying malfunctioning nodes} as
|
||||
follows:
|
||||
|
||||
We should create a generic {\bf feedback mechanism for add-on tools} like
|
||||
Mike Perry's ``Snakes on a Tor'' to report failing nodes to authorities.
|
||||
\plan{Do in 2006; 1-2 weeks.}
|
||||
|
||||
We should write tools to {\bf detect more kinds of innocent node failure},
|
||||
such as nodes whose network providers intercept SSL, nodes whose network
|
||||
providers censor popular websites, and so on. We should also try to detect
|
||||
{\bf routers that snoop traffic}; we could do this by launching connections
|
||||
to throwaway accounts, and seeing which accounts get used.\plan{Do in 2007;
|
||||
ask Mike Perry if he's interested. 4-6 weeks.}
|
||||
|
||||
We should add {\bf an efficient way for authorities to mark a set of servers
|
||||
as probably collaborating} though not necessarily otherwise dishonest.
|
||||
This happens when an administrator starts multiple routers, but doesn't mark
|
||||
them as belonging to the same family.\plan{Do during v2.1 directory protocol
|
||||
redesign; 1-2 weeks to implement.}
|
||||
|
||||
To avoid attacks where an adversary claims good performance in order to
|
||||
attract traffic, we should {\bf have authorities measure node performance}
|
||||
(including stability and bandwidth) themselves, and not simply believe what
|
||||
they're told. Measuring stability can be done by tracking MTBF. Measuring
|
||||
bandwidth can be tricky, since it's hard to distinguish between a server with
|
||||
low capacity, and a high-capacity server with most of its capacity in
|
||||
use.\plan{Do ``Stable'' in 2007; 2-3 weeks. ``Fast'' will be harder; do it
|
||||
if we can interest a grad student.}
|
||||
|
||||
{\bf Operating a directory authority should be easier.} We rely on authority
|
||||
operators to keep the network running well, but right now their job involves
|
||||
too much busywork and administrative overhead. A better interface for them
|
||||
to use could free their time to work on exception cases rather than on
|
||||
adding named nodes to the network.\plan{Do in 2007; 4-5 weeks.}
|
||||
|
||||
\subsection{Protocol security}
|
||||
|
||||
In addition to other protocol changes discussed above,
|
||||
% And should we move some of them down here? -NM
|
||||
we should add {\bf hooks for denial-of-service resistance}; we have some
|
||||
preliminary designs, but we shouldn't postpone them until we really need them.
|
||||
If somebody tries a DDoS attack against the Tor network, we won't want to
|
||||
wait for all the servers and clients to upgrade to a new
|
||||
version.\plan{Research project; do this in 2007 if funded.}
|
||||
|
||||
\section{Development infrastructure}
|
||||
|
||||
\subsection{Build farm}
|
||||
We've begun to deploy a cross-platform distributed build farm of hosts
|
||||
that build and test the Tor source every time it changes in our development
|
||||
repository.
|
||||
|
||||
We need to {\bf get more participants}, so that we can test a larger variety
|
||||
of platforms. (Previously, we've only found out when our code had broken on
|
||||
obscure platforms when somebody got around to building it.)
|
||||
|
||||
We need also to {\bf add our dependencies} to the build farm, so that we can
|
||||
ensure that libraries we need (especially libevent) do not stop working on
|
||||
any important platform between one release and the next.
|
||||
|
||||
\plan{This is ongoing as more buildbots arrive.}
|
||||
|
||||
\subsection{Improved testing harness}
|
||||
Currently, our {\bf unit tests} cover only about 20\% of the code base. This
|
||||
is uncomfortably low; we should write more and switch to a more flexible
|
||||
testing framework.\plan{Ongoing basis, time permitting.}
|
||||
|
||||
We should also write flexible {\bf automated single-host deployment tests} so
|
||||
we can more easily verify that the current codebase works with the
|
||||
network.\plan{Worthwhile in 2007; would save lots of time. 2-4 weeks.}
|
||||
|
||||
We should build automated {\bf stress testing} frameworks so we can see which
|
||||
realistic loads cause Tor to perform badly, and regularly profile Tor against
|
||||
these loads. This would give us {\it in vitro} performance values to
|
||||
supplement our deployment experience.\plan{Worthwhile in 2007; 2-6 weeks.}
|
||||
|
||||
We should improve our memory profiling code.\plan{...}
|
||||
|
||||
|
||||
\subsection{Centralized build system}
|
||||
We currently rely on a separate packager to maintain the packaging system and
|
||||
to build Tor on each platform for which we distribute binaries. Separate
|
||||
package maintainers is sensible, but separate package builders has meant
|
||||
long turnaround times between source releases and package releases. We
|
||||
should create the necessary infrastructure for us to produce binaries for all
|
||||
major packages within an hour or so of source release.\plan{We should
|
||||
brainstorm this at least in 2007.}
|
||||
|
||||
\subsection{Improved metrics}
|
||||
We need a way to {\bf measure the network's health, capacity, and degree of
|
||||
utilization}. Our current means for doing this are ad hoc and not
|
||||
completely accurate
|
||||
|
||||
We need better ways to {\bf tell which countries are users are coming from,
|
||||
and how many there are}. A good perspective of the network helps us
|
||||
allocate resources and identify trouble spots, but our current approaches
|
||||
will work less and less well as we make it harder for adversaries to
|
||||
enumerate users. We'll probably want to shift to a smarter, statistical
|
||||
approach rather than our current ``count and extrapolate'' method.
|
||||
|
||||
\plan{All of this in 2007 if funded; 4-8 weeks}
|
||||
|
||||
% \tmp{We'd like to know how much of the network is getting used.}
|
||||
% I think this is covered above -NM
|
||||
|
||||
\subsection{Controller library}
|
||||
We've done lots of design and development on our controller interface, which
|
||||
allows UI applications and other tools to interact with Tor. We could
|
||||
encourage the development of more such tools by releasing a {\bf
|
||||
general-purpose controller library}, ideally with API support for several
|
||||
popular programming languages.\plan{2006 or 2007; 1-2 weeks.}
|
||||
|
||||
\section{User experience}
|
||||
|
||||
\subsection{Get blocked less, get blocked less broadly}
|
||||
Right now, some services block connections from the Tor network because
|
||||
they don't have a better
|
||||
way to keep vandals from abusing them than blocking IP addresses associated
|
||||
with vandalism. Our approach so far has been to educate them about better
|
||||
solutions that currently exist, but we should also {\bf create better
|
||||
solutions for limiting vandalism by anonymous users} like credential and
|
||||
blind-signature based implementations, and encourage their use. Other
|
||||
promising starting points including writing a patch and explanation for
|
||||
Wikipedia, and helping Freenode to document, maintain, and expand its
|
||||
current Tor-friendly position.\plan{Do a writeup here in 2007; 1-2 weeks.}
|
||||
|
||||
Those who do block Tor users also block overbroadly, sometimes blacklisting
|
||||
operators of Tor servers that do not permit exit to their services. We could
|
||||
obviate innocent reasons for doing so by designing a {\bf narrowly-targeted Tor
|
||||
RBL service} so that those who wanted to overblock Tor could no longer
|
||||
plead incompetence.\plan{Possibly in 2007 if we decide it's a good idea; 3
|
||||
weeks.}
|
||||
|
||||
\subsection{All-in-one bundle}
|
||||
We need a well-tested, well-documented bundle of Tor and supporting
|
||||
applications configured to use it correctly. We have an initial
|
||||
implementation well under way, but it will need additional work in
|
||||
identifying requisite Firefox extensions, identifying security threats,
|
||||
improving user experience, and so on. This will need significantly more work
|
||||
before it's ready for a general public release.
|
||||
|
||||
\subsection{LiveCD Tor}
|
||||
We need a nice bootable livecd containing a minimal OS and a few applications
|
||||
configured to use it correctly. The Anonym.OS project demonstrated that this
|
||||
is quite feasible, but their project is not currently maintained.
|
||||
|
||||
\subsection{A Tor client in a VM}
|
||||
\tmp{a.k.a JanusVM} which is quite related to the firewall-level deployment
|
||||
section below. JanusVM is a Linux kernel running in VMWare. It gets an IP
|
||||
address from the network, and serves as a DHCP server for its host Windows
|
||||
machine. It intercepts all outgoing traffic and redirects it into Privoxy,
|
||||
Tor, etc. This Linux-in-Windows approach may help us with scalability in
|
||||
the short term, and it may also be a good long-term solution rather than
|
||||
accepting all security risks in Windows.
|
||||
|
||||
%\subsection{Interface improvements}
|
||||
%\tmp{Allow controllers to manipulate server status.}
|
||||
% (Why is this in the User Experience section?) -RD
|
||||
% I think it's better left to a generic ``make controller iface better'' item.
|
||||
|
||||
\subsection{Firewall-level deployment}
|
||||
Another useful deployment mode for some users is using {\bf Tor in a firewall
|
||||
configuration}, and directing all their traffic through Tor. This can be a
|
||||
little tricky to set up currently, but it's an effective way to make sure no
|
||||
traffic leaves the host un-anonymized. To achieve this, we need to {\bf
|
||||
improve and port our new TransPort} feature which allows Tor to be used
|
||||
without SOCKS support; to {\bf add an anonymizing DNS proxy} feature to Tor;
|
||||
and to {\bf construct a recommended set of firewall configurations} to redirect
|
||||
traffic to Tor.
|
||||
|
||||
This is an area where {\bf deployment via a livecd}, or an installation
|
||||
targeted at specialized home routing hardware, could be useful.
|
||||
|
||||
\subsection{Assess software and configurations for anonymity risks}
|
||||
Right now, users and packagers are more or less on their own when selecting
|
||||
Firefox extensions. We should {\bf assemble a recommended list of browser
|
||||
extensions} through experiment, and include this in the application bundles
|
||||
we distribute.
|
||||
|
||||
We should also describe {\bf best practices for using Tor with each class of
|
||||
application}. For example, Ethan Zuckerman has written a detailed
|
||||
tutorial on how to use Tor, Firefox, GMail, and Wordpress to blog with
|
||||
improved safety. There are many other cases on the Internet where anonymity
|
||||
would be helpful, and there are a lot of ways to screw up using Tor.
|
||||
|
||||
The Foxtor and Torbutton extensions serve similar purposes; we should pick a
|
||||
favorite, and merge in the useful features of the other.
|
||||
|
||||
%\tmp{clean up our own bundled software:
|
||||
%E.g. Merge the good features of Foxtor into Torbutton}
|
||||
%
|
||||
% What else did you have in mind? -NM
|
||||
|
||||
\subsection{Localization}
|
||||
Right now, most of our user-facing code is internationalized. We need to
|
||||
internationalize the last few hold-outs (like the Tor expert installer), and get
|
||||
more translations for the parts that are already internationalized.
|
||||
|
||||
Also, we should look into a {\bf unified translator's solution}. Currently,
|
||||
since different tools have been internationalized using the
|
||||
framework-appropriate method, different tools require translators to localize
|
||||
them via different interfaces. Inasmuch as possible, we should make
|
||||
translators only need to use a single tool to translate the whole Tor suite.
|
||||
|
||||
\section{Support}
|
||||
|
||||
It would be nice to set up some {\bf user support infrastructure} and
|
||||
{\bf contributor support infrastructure}, especially focusing on server
|
||||
operators and on coordinating volunteers.
|
||||
|
||||
This includes intuitive and easy ticket systems for bug reports and
|
||||
feature suggestions (not just mailing lists with a half dozen people
|
||||
and no clear roles for who answers what), but it also includes a more
|
||||
personalized and efficient framework for interaction so we keep the
|
||||
attention and interest of the contributors, and so we make them feel
|
||||
helpful and wanted.
|
||||
|
||||
\section{Documentation}
|
||||
|
||||
\subsection{Unified documentation scheme}
|
||||
|
||||
We need to {\bf inventory our documentation.} Our documentation so far has
|
||||
been mostly produced on an {\it ad hoc} basis, in response to particular
|
||||
needs and requests. We should figure out what documentation we have, which of
|
||||
it (if any) should get priority, and whether we can't put it all into a
|
||||
single format.
|
||||
|
||||
We could {\bf unify the docs} into a single book-like thing. This will also
|
||||
help us identify what sections of the ``book'' are missing.
|
||||
|
||||
\subsection{Missing technical documentation}
|
||||
|
||||
We should {\bf revise our design paper} to reflect the new decisions and
|
||||
research we've made since it was published in 2004. This will help other
|
||||
researchers evaluate and suggest improvements to Tor's current design.
|
||||
|
||||
Other projects sometimes implement the client side of our protocol. We
|
||||
encourage this, but we should write {\bf a document about how to avoid
|
||||
excessive resource use}, so we don't need to worry that they will do so
|
||||
without regard to the effect of their choices on server resources.
|
||||
|
||||
\subsection{Missing user documentation}
|
||||
|
||||
Our documentation falls into two broad categories: some is `discoursive' and
|
||||
explains in detail why users should take certain actions, and other
|
||||
documentation is `comprehensive' and describes all of Tor's features. Right
|
||||
now, we have no document that is both deep, readable, and thorough. We
|
||||
should correct this by identifying missing spots in our design.
|
||||
|
||||
\bibliographystyle{plain} \bibliography{tor-design}
|
||||
|
||||
\end{document}
|
||||
|
||||
Binary file not shown.
@ -1,895 +0,0 @@
|
||||
\documentclass{article}
|
||||
|
||||
\usepackage{url}
|
||||
\usepackage{fullpage}
|
||||
|
||||
\newenvironment{tightlist}{\begin{list}{$\bullet$}{
|
||||
\setlength{\itemsep}{0mm}
|
||||
\setlength{\parsep}{0mm}
|
||||
% \setlength{\labelsep}{0mm}
|
||||
% \setlength{\labelwidth}{0mm}
|
||||
% \setlength{\topsep}{0mm}
|
||||
}}{\end{list}}
|
||||
\newcommand{\tmp}[1]{{\bf #1} [......] \\}
|
||||
\newcommand{\plan}[1]{ {\bf (#1)}}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Tor Development Roadmap: Wishlist for 2008 and beyond}
|
||||
\author{Roger Dingledine \and Nick Mathewson}
|
||||
\date{}
|
||||
|
||||
\maketitle
|
||||
\pagestyle{plain}
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
Tor (the software) and Tor (the overall software/network/support/document
|
||||
suite) are now experiencing all the crises of success. Over the next
|
||||
years, we're probably going to grow even more in terms of users, developers,
|
||||
and funding than before. This document attempts to lay out all the
|
||||
well-understood next steps that Tor needs to take. We should periodically
|
||||
reorganize it to reflect current and intended priorities.
|
||||
|
||||
\section{Everybody can be a relay}
|
||||
|
||||
We've made a lot of progress towards letting an ordinary Tor client also
|
||||
serve as a Tor relay. But these issues remain.
|
||||
|
||||
\subsection{UPNP}
|
||||
|
||||
We should teach Vidalia how to speak UPNP to automatically open and
|
||||
forward ports on common (e.g. Linksys) routers. There are some promising
|
||||
Qt-based UPNP libs out there, and in any case there are others (e.g. in
|
||||
Perl) that we can base it on.
|
||||
|
||||
\subsection{``ORPort auto'' to look for a reachable port}
|
||||
|
||||
Vidalia defaults to port 443 on Windows and port 8080 elsewhere. But if
|
||||
that port is already in use, or the ISP filters incoming connections
|
||||
on that port (some cablemodem providers filter 443 inbound), the user
|
||||
needs to learn how to notice this, and then pick a new one and type it
|
||||
into Vidalia.
|
||||
|
||||
We should add a new option ``auto'' that cycles through a set of preferred
|
||||
ports, testing bindability and reachability for each of them, and only
|
||||
complains to the user once it's given up on the common choices.
|
||||
|
||||
\subsection{Incentives design}
|
||||
|
||||
Roger has been working with researchers at Rice University to simulate
|
||||
and analyze a new design where the directory authorities assign gold
|
||||
stars to well-behaving relays, and then all the relays give priority
|
||||
to traffic from gold-starred relays. The great feature of the design is
|
||||
that not only does it provide the (explicit) incentive to run a relay,
|
||||
but it also aims to grow the overall capacity of the network, so even
|
||||
non-relays will benefit.
|
||||
|
||||
It needs more analysis, and perhaps more design work, before we try
|
||||
deploying it.
|
||||
|
||||
\subsection{Windows libevent}
|
||||
|
||||
Tor relays still don't work well or reliably on Windows XP or Windows
|
||||
Vista, because we don't use the Windows-native ``overlapped IO''
|
||||
approach. Christian King made a good start at teaching libevent about
|
||||
overlapped IO during Google Summer of Code 2007, and next steps are
|
||||
to a) finish that, b) teach Tor to do openssl calls on buffers rather
|
||||
than directly to the network, and c) teach Tor to use the new libevent
|
||||
buffers approach.
|
||||
|
||||
\subsection{Network scaling}
|
||||
|
||||
If we attract many more relays, we will need to handle the growing pains
|
||||
in terms of getting all the directory information to all the users.
|
||||
|
||||
The first piece of this issue is a practical question: since the
|
||||
directory size scales linearly with more relays, at some point it
|
||||
will no longer be practical for every client to learn about every
|
||||
relay. We can try to reduce the amount of information each client needs
|
||||
to fetch (e.g. based on fetching less information preemptively as in
|
||||
Section~\ref{subsec:fewer-descriptor-fetches} below), but eventually
|
||||
clients will need to learn about only a subset of the network, and we
|
||||
will need to design good ways to divide up the network information.
|
||||
|
||||
The second piece is an anonymity question that arises from this
|
||||
partitioning: if Tor's security comes from having all the clients
|
||||
behaving in similar ways, yet we are now giving different clients
|
||||
different directory information, how can we minimize the new anonymity
|
||||
attacks we introduce?
|
||||
|
||||
\subsection{Using fewer sockets}
|
||||
|
||||
Since in the current network every Tor relay can reach every other Tor
|
||||
relay, and we have many times more users than relays, pretty much every
|
||||
possible link in the network is in use. That is, the current network
|
||||
is a clique in practice.
|
||||
|
||||
And since each of these connections requires a TCP socket, it's going
|
||||
to be hard for the network to grow much larger: many systems come with
|
||||
a default of 1024 file descriptors allowed per process, and raising
|
||||
that ulimit is hard for end users. Worse, many low-end gateway/firewall
|
||||
routers can't handle this many connections in their routing table.
|
||||
|
||||
One approach is a restricted-route topology~\cite{danezis:pet2003}:
|
||||
predefine which relays can reach which other relays, and communicate
|
||||
these restrictions to the relays and the clients. We need to compute
|
||||
which links are acceptable in a way that's decentralized yet scalable,
|
||||
and in a way that achieves a small-worlds property; and we
|
||||
need an efficient (compact) way to characterize the topology information
|
||||
so all the users could keep up to date.
|
||||
|
||||
Another approach would be to switch to UDP-based transport between
|
||||
relays, so we don't need to keep the TCP sockets open at all. Needs more
|
||||
investigation too.
|
||||
|
||||
\subsection{Auto bandwidth detection and rate limiting, especially for
|
||||
asymmetric connections.}
|
||||
|
||||
|
||||
\subsection{Better algorithms for giving priority to local traffic}
|
||||
|
||||
Proposal 111 made a lot of progress at separating local traffic from
|
||||
relayed traffic, so Tor users can rate limit the relayed traffic at a
|
||||
stricter level. But since we want to pass both traffic classes over the
|
||||
same TCP connection, we can't keep them entirely separate. The current
|
||||
compromise is that we treat all bytes to/from a given connectin as
|
||||
local traffic if any of the bytes within the past N seconds were local
|
||||
bytes. But a) we could use some more intelligent heuristics, and b)
|
||||
this leaks information to an active attacker about when local traffic
|
||||
was sent/received.
|
||||
|
||||
\subsection{Tolerate absurdly wrong clocks, even for relays}
|
||||
|
||||
Many of our users are on Windows, running with a clock several days or
|
||||
even several years off from reality. Some of them are even intentionally
|
||||
in this state so they can run software that will only run in the past.
|
||||
|
||||
Before Tor 0.1.1.x, Tor clients would still function if their clock was
|
||||
wildly off --- they simply got a copy of the directory and believed it.
|
||||
Starting in Tor 0.1.1.x (and even moreso in Tor 0.2.0.x), the clients
|
||||
only use networkstatus documents that they believe to be recent, so
|
||||
clients with extremely wrong clocks no longer work. (This bug has been
|
||||
an unending source of vague and confusing bug reports.)
|
||||
|
||||
The first step is for clients to recognize when all the directory material
|
||||
they're fetching has roughly the same offset from their current time,
|
||||
and then automatically correct for it.
|
||||
|
||||
Once that's working well, clients who opt to become bridge relays should
|
||||
be able to use the same approach to serve accurate directory information
|
||||
to their bridge users.
|
||||
|
||||
\subsection{Risks from being a relay}
|
||||
|
||||
Three different research
|
||||
papers~\cite{back01,clog-the-queue,attack-tor-oak05} describe ways to
|
||||
identify the nodes in a circuit by running traffic through candidate nodes
|
||||
and looking for dips in the traffic while the circuit is active. These
|
||||
clogging attacks are not that scary in the Tor context so long as relays
|
||||
are never clients too. But if we're trying to encourage more clients to
|
||||
turn on relay functionality too (whether as bridge relays or as normal
|
||||
relays), then we need to understand this threat better and learn how to
|
||||
mitigate it.
|
||||
|
||||
One promising research direction is to investigate the RelayBandwidthRate
|
||||
feature that lets Tor rate limit relayed traffic differently from local
|
||||
traffic. Since the attacker's ``clogging'' traffic is not in the same
|
||||
bandwidth class as the traffic initiated by the user, it may be harder
|
||||
to detect interference. Or it may not be.
|
||||
|
||||
\subsection{First a bridge, then a public relay?}
|
||||
|
||||
Once enough of the items in this section are done, I want all clients
|
||||
to start out automatically detecting their reachability and opting
|
||||
to be bridge relays.
|
||||
|
||||
Then if they realize they have enough consistency and bandwidth, they
|
||||
should automatically upgrade to being non-exit relays.
|
||||
|
||||
What metrics should we use for deciding when we're fast enough
|
||||
and stable enough to switch? Given that the list of bridge relays needs
|
||||
to be kept secret, it doesn't make much sense to switch back.
|
||||
|
||||
\section{Tor on low resources / slow links}
|
||||
\subsection{Reducing directory fetches further}
|
||||
\label{subsec:fewer-descriptor-fetches}
|
||||
\subsection{AvoidDiskWrites}
|
||||
\subsection{Using less ram}
|
||||
\subsection{Better DoS resistance for tor servers / authorities}
|
||||
\section{Blocking resistance}
|
||||
\subsection{Better bridge-address-distribution strategies}
|
||||
\subsection{Get more volunteers running bridges}
|
||||
\subsection{Handle multiple bridge authorities}
|
||||
\subsection{Anonymity for bridge users: second layer of entry guards, etc?}
|
||||
\subsection{More TLS normalization}
|
||||
\subsection{Harder to block Tor software distribution}
|
||||
\subsection{Integration with Psiphon}
|
||||
\section{Packaging}
|
||||
\subsection{Switch Privoxy out for Polipo}
|
||||
- Make Vidalia able to launch more programs itself
|
||||
\subsection{Continue Torbutton improvements}
|
||||
especially better docs
|
||||
\subsection{Vidalia and stability (especially wrt ongoing Windows problems)}
|
||||
learn how to get useful crash reports (tracebacks) from Windows users
|
||||
\subsection{Polipo support on Windows}
|
||||
\subsection{Auto update for Tor, Vidalia, others}
|
||||
\subsection{Tor browser bundle for USB and standalone use}
|
||||
\subsection{LiveCD solution}
|
||||
\subsection{VM-based solution}
|
||||
\subsection{Tor-on-enclave-firewall configuration}
|
||||
\subsection{General tutorials on what common applications are Tor-friendly}
|
||||
\subsection{Controller libraries (torctl) plus documentation}
|
||||
\subsection{Localization and translation (Vidalia, Torbutton, web pages)}
|
||||
\section{Interacting better with Internet sites}
|
||||
\subsection{Make tordnsel (tor exitlist) better and more well-known}
|
||||
\subsection{Nymble}
|
||||
\subsection{Work with Wikipedia, Slashdot, Google(, IRC networks)}
|
||||
\subsection{IPv6 support for exit destinations}
|
||||
\section{Network health}
|
||||
\subsection{torflow / soat to detect bad relays}
|
||||
\subsection{make authorities more automated}
|
||||
\subsection{torstatus pages and better trend tracking}
|
||||
\subsection{better metrics for assessing network health / growth}
|
||||
- geoip usage-by-country reporting and aggregation
|
||||
(Once that's working, switch to Directory guards)
|
||||
\section{Performance research}
|
||||
\subsection{Load balance better}
|
||||
\subsection{Improve our congestion control algorithms}
|
||||
\subsection{Two-hops vs Three-hops}
|
||||
\subsection{Transport IP packets end-to-end}
|
||||
\section{Outreach and user education}
|
||||
\subsection{"Who uses Tor" use cases}
|
||||
\subsection{Law enforcement contacts}
|
||||
- "Was this IP address a Tor relay recently?" database
|
||||
\subsection{Commercial/enterprise outreach. Help them use Tor well and
|
||||
not fear it.}
|
||||
\subsection{NGO outreach and training.}
|
||||
- "How to be a safe blogger"
|
||||
\subsection{More activist coordinators, more people to answer user questions}
|
||||
\subsection{More people to hold hands of server operators}
|
||||
\subsection{Teaching the media about Tor}
|
||||
\subsection{The-dangers-of-plaintext awareness}
|
||||
\subsection{check.torproject.org and other "privacy checkers"}
|
||||
\subsection{Stronger legal FAQ for US}
|
||||
\subsection{Legal FAQs for other countries}
|
||||
\section{Anonymity research}
|
||||
\subsection{estimate relay bandwidth more securely}
|
||||
\subsection{website fingerprinting attacks}
|
||||
\subsection{safer e2e defenses}
|
||||
\subsection{Using Tor when you really need anonymity. Can you compose it
|
||||
with other steps, like more trusted guards or separate proxies?}
|
||||
\subsection{Topology-aware routing; routing-zones, steven's pet2007 paper.}
|
||||
\subsection{Exactly what do guard nodes provide?}
|
||||
|
||||
Entry guards seem to defend against all sorts of attacks. Can we work
|
||||
through all the benefits they provide? Papers like Nikita's CCS 2007
|
||||
paper make me think their value is not well-understood by the research
|
||||
community.
|
||||
|
||||
\section{Organizational growth and stability}
|
||||
\subsection{A contingency plan if Roger gets hit by a bus}
|
||||
- Get a new executive director
|
||||
\subsection{More diversity of funding}
|
||||
- Don't rely on any one funder as much
|
||||
- Don't rely on any sector or funder category as much
|
||||
\subsection{More Tor-funded people who are skilled at peripheral apps like
|
||||
Vidalia, Torbutton, Polipo, etc}
|
||||
\subsection{More coordinated media handling and strategy}
|
||||
\subsection{Clearer and more predictable trademark behavior}
|
||||
\subsection{More outside funding for internships, etc e.g. GSoC.}
|
||||
\section{Hidden services}
|
||||
\subsection{Scaling: how to handle many hidden services}
|
||||
\subsection{Performance: how to rendezvous with them quickly}
|
||||
\subsection{Authentication/authorization: how to tolerate DoS / load}
|
||||
\section{Tor as a general overlay network}
|
||||
\subsection{Choose paths / exit by country}
|
||||
\subsection{Easier to run your own private servers and have Tor use them
|
||||
anywhere in the path}
|
||||
\subsection{Easier to run an independent Tor network}
|
||||
\section{Code security/correctness}
|
||||
\subsection{veracode}
|
||||
\subsection{code audit}
|
||||
\subsection{more fuzzing tools}
|
||||
\subsection{build farm, better testing harness}
|
||||
\subsection{Long-overdue code refactoring and cleanup}
|
||||
\section{Protocol security}
|
||||
\subsection{safer circuit handshake}
|
||||
\subsection{protocol versioning for future compatibility}
|
||||
\subsection{cell sizes}
|
||||
\subsection{adapt to new key sizes, etc}
|
||||
|
||||
\bibliographystyle{plain} \bibliography{tor-design}
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
|
||||
\section{Code and design infrastructure}
|
||||
|
||||
\subsection{Protocol revision}
|
||||
To maintain backward compatibility, we've postponed major protocol
|
||||
changes and redesigns for a long time. Because of this, there are a number
|
||||
of sensible revisions we've been putting off until we could deploy several of
|
||||
them at once. To do each of these, we first need to discuss design
|
||||
alternatives with other cryptographers and outside collaborators to
|
||||
make sure that our choices are secure.
|
||||
|
||||
First of all, our protocol needs better {\bf versioning support} so that we
|
||||
can make backward-incompatible changes to our core protocol. There are
|
||||
difficult anonymity issues here, since many naive designs would make it easy
|
||||
to tell clients apart (and then track them) based on their supported versions.
|
||||
|
||||
With protocol versioning support would come the ability to {\bf future-proof
|
||||
our ciphersuites}. For example, not only our OR protocol, but also our
|
||||
directory protocol, is pretty firmly tied to the SHA-1 hash function, which
|
||||
though not yet known to be insecure for our purposes, has begun to show
|
||||
its age. We should
|
||||
remove assumptions throughout our design based on the assumption that public
|
||||
keys, secret keys, or digests will remain any particular size indefinitely.
|
||||
|
||||
Our OR {\bf authentication protocol}, though provably
|
||||
secure\cite{tap:pet2006}, relies more on particular aspects of RSA and our
|
||||
implementation thereof than we had initially believed. To future-proof
|
||||
against changes, we should replace it with a less delicate approach.
|
||||
|
||||
\plan{For all the above: 2 person-months to specify, spread over several
|
||||
months with time for interaction with external participants. One
|
||||
person-month to implement. Start specifying in early 2007.}
|
||||
|
||||
We might design a {\bf stream migration} feature so that streams tunneled
|
||||
over Tor could be more resilient to dropped connections and changed IPs.
|
||||
\plan{Not in 2007.}
|
||||
|
||||
A new protocol could support {\bf multiple cell sizes}. Right now, all data
|
||||
passes through the Tor network divided into 512-byte cells. This is
|
||||
efficient for high-bandwidth protocols, but inefficient for protocols
|
||||
like SSH or AIM that send information in small chunks. Of course, we need to
|
||||
investigate the extent to which multiple sizes could make it easier for an
|
||||
adversary to fingerprint a traffic pattern. \plan{Not in 2007.}
|
||||
|
||||
As a part of our design, we should investigate possible {\bf cipher modes}
|
||||
other than counter mode. For example, a mode with built-in integrity
|
||||
checking, error propagation, and random access could simplify our protocol
|
||||
significantly. Sadly, many of these are patented and unavailable for us.
|
||||
\plan{Not in 2007.}
|
||||
|
||||
\subsection{Scalability}
|
||||
|
||||
\subsubsection{Improved directory efficiency}
|
||||
|
||||
We should {\bf have routers upload their descriptors even less often}, so
|
||||
that clients do not need to download replacements every 18 hours whether any
|
||||
information has changed or not. (As of Tor 0.1.2.3-alpha, clients tolerate
|
||||
routers that don't upload often, but routers still upload at least every 18
|
||||
hours to support older clients.) \plan{Must do, but not until 0.1.1.x is
|
||||
deprecated in mid 2007. 1 week.}
|
||||
|
||||
\subsubsection{Non-clique topology}
|
||||
Our current network design achieves a certain amount of its anonymity by
|
||||
making clients act like each other through the simple expedient of making
|
||||
sure that all clients know all servers, and that any server can talk to any
|
||||
other server. But as the number of servers increases to serve an
|
||||
ever-greater number of clients, these assumptions become impractical.
|
||||
|
||||
At worst, if these scalability issues become troubling before a solution is
|
||||
found, we can design and build a solution to {\bf split the network into
|
||||
multiple slices} until a better solution comes along. This is not ideal,
|
||||
since rather than looking like all other users from a point of view of path
|
||||
selection, users would ``only'' look like 200,000--300,000 other
|
||||
users.\plan{Not unless needed.}
|
||||
|
||||
We are in the process of designing {\bf improved schemes for network
|
||||
scalability}. Some approaches focus on limiting what an adversary can know
|
||||
about what a user knows; others focus on reducing the extent to which an
|
||||
adversary can exploit this knowledge. These are currently in their infancy,
|
||||
and will probably not be needed in 2007, but they must be designed in 2007 if
|
||||
they are to be deployed in 2008.\plan{Design in 2007; unknown difficulty.
|
||||
Write a paper.}
|
||||
|
||||
\subsubsection{Relay incentives}
|
||||
To support more users on the network, we need to get more servers. So far,
|
||||
we've relied on volunteerism to attract server operators, and so far it's
|
||||
served us well. But in the long run, we need to {\bf design incentives for
|
||||
users to run servers} and relay traffic for others. Most obviously, we
|
||||
could try to build the network so that servers offered improved service for
|
||||
other servers, but we would need to do so without weakening anonymity and
|
||||
making it obvious which connections originate from users running servers. We
|
||||
have some preliminary designs~\cite{incentives-txt,tor-challenges},
|
||||
but need to perform
|
||||
some more research to make sure they would be safe and effective.\plan{Write
|
||||
a draft paper; 2 person-months.}
|
||||
(XXX we did that)
|
||||
|
||||
\subsection{Portability}
|
||||
Our {\bf Windows implementation}, though much improved, continues to lag
|
||||
behind Unix and Mac OS X, especially when running as a server. We hope to
|
||||
merge promising patches from Christian King to address this point, and bring
|
||||
Windows performance on par with other platforms.\plan{Do in 2007; 1.5 months
|
||||
to integrate not counting Mike's work.}
|
||||
|
||||
We should have {\bf better support for portable devices}, including modes of
|
||||
operation that require less RAM, and that write to disk less frequently (to
|
||||
avoid wearing out flash RAM).\plan{Optional; 2 weeks.}
|
||||
|
||||
\subsection{Performance: resource usage}
|
||||
We've been working on {\bf using less RAM}, especially on servers. This has
|
||||
paid off a lot for directory caches in the 0.1.2, which in some cases are
|
||||
using 90\% less memory than they used to require. But we can do better,
|
||||
especially in the area around our buffer management algorithms, by using an
|
||||
approach more like the BSD and Linux kernels use instead of our current ring
|
||||
buffer approach. (For OR connections, we can just use queues of cell-sized
|
||||
chunks produced with a specialized allocator.) This could potentially save
|
||||
around 25 to 50\% of the memory currently allocated for network buffers, and
|
||||
make Tor a more attractive proposition for restricted-memory environments
|
||||
like old computers, mobile devices, and the like.\plan{Do in 2007; 2-3 weeks
|
||||
plus one week measurement.} (XXX We did this, but we need to do something
|
||||
more/else.)
|
||||
|
||||
\subsection{Performance: network usage}
|
||||
We know too little about how well our current path
|
||||
selection algorithms actually spread traffic around the network in practice.
|
||||
We should {\bf research the efficacy of our traffic allocation} and either
|
||||
assure ourselves that it is close enough to optimal as to need no improvement
|
||||
(unlikely) or {\bf identify ways to improve network usage}, and get more
|
||||
users' traffic delivered faster. Performing this research will require
|
||||
careful thought about anonymity implications.
|
||||
|
||||
We should also {\bf examine the efficacy of our congestion control
|
||||
algorithm}, and see whether we can improve client performance in the
|
||||
presence of a congested network through dynamic `sendme' window sizes or
|
||||
other means. This will have anonymity implications too if we aren't careful.
|
||||
|
||||
\plan{For both of the above: research, design and write
|
||||
a measurement tool in 2007: 1 month. See if we can interest a graduate
|
||||
student.}
|
||||
|
||||
We should work on making Tor's cell-based protocol perform better on
|
||||
networks with low bandwidth
|
||||
and high packet loss.\plan{Do in 2007 if we're funded to do it; 4-6 weeks.}
|
||||
|
||||
\subsection{Performance scenario: one Tor client, many users}
|
||||
We should {\bf improve Tor's performance when a single Tor handles many
|
||||
clients}. Many organizations want to manage a single Tor client on their
|
||||
firewall for many users, rather than having each user install a separate
|
||||
Tor client. We haven't optimized for this scenario, and it is likely that
|
||||
there are some code paths in the current implementation that become
|
||||
inefficient when a single Tor is servicing hundreds or thousands of client
|
||||
connections. (Additionally, it is likely that such clients have interesting
|
||||
anonymity requirements the we should investigate.) We should profile Tor
|
||||
under appropriate loads, identify bottlenecks, and fix them.\plan{Do in 2007
|
||||
if we're funded to do it; 4-8 weeks.}
|
||||
|
||||
\subsection{Tor servers on asymmetric bandwidth}
|
||||
|
||||
Tor should work better on servers that have asymmetric connections like cable
|
||||
or DSL. Because Tor has separate TCP connections between each
|
||||
hop, if the incoming bytes are arriving just fine and the outgoing bytes are
|
||||
all getting dropped on the floor, the TCP push-back mechanisms don't really
|
||||
transmit this information back to the incoming streams.\plan{Do in 2007 since
|
||||
related to bandwidth limiting. 3-4 weeks.}
|
||||
|
||||
\subsection{Running Tor as both client and server}
|
||||
|
||||
Many performance tradeoffs and balances that might need more attention.
|
||||
We first need to track and fix whatever bottlenecks emerge; but we also
|
||||
need to invent good algorithms for prioritizing the client's traffic
|
||||
without starving the server's traffic too much.\plan{No idea; try
|
||||
profiling and improving things in 2007.}
|
||||
|
||||
\subsection{Protocol redesign for UDP}
|
||||
Tor has relayed only TCP traffic since its first versions, and has used
|
||||
TLS-over-TCP to do so. This approach has proved reliable and flexible, but
|
||||
in the long term we will need to allow UDP traffic on the network, and switch
|
||||
some or all of the network to using a UDP transport. {\bf Supporting UDP
|
||||
traffic} will make Tor more suitable for protocols that require UDP, such
|
||||
as many VOIP protocols. {\bf Using a UDP transport} could greatly reduce
|
||||
resource limitations on servers, and make the network far less interruptible
|
||||
by lossy connections. Either of these protocol changes would require a great
|
||||
deal of design work, however. We hope to be able to enlist the aid of a few
|
||||
talented graduate students to assist with the initial design and
|
||||
specification, but the actual implementation will require significant testing
|
||||
of different reliable transport approaches.\plan{Maybe do a design in 2007 if
|
||||
we find an interested academic. Ian or Ben L might be good partners here.}
|
||||
|
||||
\section{Blocking resistance}
|
||||
|
||||
\subsection{Design for blocking resistance}
|
||||
We have written a design document explaining our general approach to blocking
|
||||
resistance. We should workshop it with other experts in the field to get
|
||||
their ideas about how we can improve Tor's efficacy as an anti-censorship
|
||||
tool.
|
||||
|
||||
\subsection{Implementation: client-side and bridges-side}
|
||||
|
||||
Bridges will want to be able to {\bf listen on multiple addresses and ports}
|
||||
if they can, to give the adversary more ports to block.
|
||||
|
||||
\subsection{Research: anonymity implications from becoming a bridge}
|
||||
|
||||
see arma's bridge proposal; e.g. should bridge users use a second layer of
|
||||
entry guards?
|
||||
|
||||
\subsection{Implementation: bridge authority}
|
||||
|
||||
we run some
|
||||
directory authorities with a slightly modified protocol that doesn't leak
|
||||
the entire list of bridges. Thus users can learn up-to-date information
|
||||
for bridges they already know about, but they can't learn about arbitrary
|
||||
new bridges.
|
||||
|
||||
we need a design for distributing the bridge authority over more than one
|
||||
server
|
||||
|
||||
\subsection{Normalizing the Tor protocol on the wire}
|
||||
Additionally, we should {\bf resist content-based filters}. Though an
|
||||
adversary can't see what users are saying, some aspects of our protocol are
|
||||
easy to fingerprint {\em as} Tor. We should correct this where possible.
|
||||
|
||||
Look like Firefox; or look like nothing?
|
||||
Future research: investigate timing similarities with other protocols.
|
||||
|
||||
\subsection{Research: scanning-resistance}
|
||||
|
||||
\subsection{Research/Design/Impl: how users discover bridges}
|
||||
Our design anticipates an arms race between discovery methods and censors.
|
||||
We need to begin the infrastructure on our side quickly, preferably in a
|
||||
flexible language like Python, so we can adapt quickly to censorship.
|
||||
|
||||
phase one: personal bridges
|
||||
phase two: families of personal bridges
|
||||
phase three: more structured social network
|
||||
phase four: bag of tricks
|
||||
Research: phase five...
|
||||
|
||||
Integration with Psiphon, etc?
|
||||
|
||||
\subsection{Document best practices for users}
|
||||
Document best practices for various activities common among
|
||||
blocked users (e.g. WordPress use).
|
||||
|
||||
\subsection{Research: how to know if a bridge has been blocked?}
|
||||
|
||||
\subsection{GeoIP maintenance, and "private" user statistics}
|
||||
How to know if the whole idea is working?
|
||||
|
||||
\subsection{Research: hiding whether the user is reading or publishing?}
|
||||
|
||||
\subsection{Research: how many bridges do you need to know to maintain
|
||||
reachability?}
|
||||
|
||||
\subsection{Resisting censorship of the Tor website, docs, and mirrors}
|
||||
|
||||
We should take some effort to consider {\bf initial distribution of Tor and
|
||||
related information} in countries where the Tor website and mirrors are
|
||||
censored. (Right now, most countries that block access to Tor block only the
|
||||
main website and leave mirrors and the network itself untouched.) Falling
|
||||
back on word-of-mouth is always a good last resort, but we should also take
|
||||
steps to make sure it's relatively easy for users to get ahold of a copy.
|
||||
|
||||
\section{Security}
|
||||
|
||||
\subsection{Security research projects}
|
||||
|
||||
We should investigate approaches with some promise to help Tor resist
|
||||
end-to-end traffic correlation attacks. It's an open research question
|
||||
whether (and to what extent) {\bf mixed-latency} networks, {\bf low-volume
|
||||
long-distance padding}, or other approaches can resist these attacks, which
|
||||
are currently some of the most effective against careful Tor users. We
|
||||
should research these questions and perform simulations to identify
|
||||
opportunities for strengthening our design without dropping performance to
|
||||
unacceptable levels. %Cite something
|
||||
\plan{Start doing this in 2007; write a paper. 8-16 weeks.}
|
||||
|
||||
We've got some preliminary results suggesting that {\bf a topology-aware
|
||||
routing algorithm}~\cite{feamster:wpes2004} could reduce Tor users'
|
||||
vulnerability against local or ISP-level adversaries, by ensuring that they
|
||||
are never in a position to watch both ends of a connection. We need to
|
||||
examine the effects of this approach in more detail and consider side-effects
|
||||
on anonymity against other kinds of adversaries. If the approach still looks
|
||||
promising, we should investigate ways for clients to implement it (or an
|
||||
approximation of it) without having to download routing tables for the whole
|
||||
Internet. \plan{Not in 2007 unless a graduate student wants to do it.}
|
||||
|
||||
%\tmp{defenses against end-to-end correlation} We don't expect any to work
|
||||
%right now, but it would be useful to learn that one did. Alternatively,
|
||||
%proving that one didn't would free up researchers in the field to go work on
|
||||
%other things.
|
||||
%
|
||||
% See above; I think I got this.
|
||||
|
||||
We should research the efficacy of {\bf website fingerprinting} attacks,
|
||||
wherein an adversary tries to match the distinctive traffic and timing
|
||||
pattern of the resources constituting a given website to the traffic pattern
|
||||
of a user's client. These attacks work great in simulations, but in
|
||||
practice we hear they don't work nearly as well. We should get some actual
|
||||
numbers to investigate the issue, and figure out what's going on. If we
|
||||
resist these attacks, or can improve our design to resist them, we should.
|
||||
% add cites
|
||||
\plan{Possibly part of end-to-end correlation paper. Otherwise, not in 2007
|
||||
unless a graduate student is interested.}
|
||||
|
||||
\subsection{Implementation security}
|
||||
|
||||
We should also {\bf mark RAM that holds key material as non-swappable} so
|
||||
that there is no risk of recovering key material from a hard disk
|
||||
compromise. This would require submitting patches upstream to OpenSSL, where
|
||||
support for marking memory as sensitive is currently in a very preliminary
|
||||
state.\plan{Nice to do, but not in immediate Tor scope.}
|
||||
|
||||
There are numerous tools for identifying trouble spots in code (such as
|
||||
Coverity or even VS2005's code analysis tool) and we should convince somebody
|
||||
to run some of them against the Tor codebase. Ideally, we could figure out a
|
||||
way to get our code checked periodically rather than just once.\plan{Almost
|
||||
no time once we talk somebody into it.}
|
||||
|
||||
We should try {\bf protocol fuzzing} to identify errors in our
|
||||
implementation.\plan{Not in 2007 unless we find a grad student or
|
||||
undergraduate who wants to try.}
|
||||
|
||||
Our guard nodes help prevent an attacker from being able to become a chosen
|
||||
client's entry point by having each client choose a few favorite entry points
|
||||
as ``guards'' and stick to them. We should implement a {\bf directory
|
||||
guards} feature to keep adversaries from enumerating Tor users by acting as
|
||||
a directory cache.\plan{Do in 2007; 2 weeks.}
|
||||
|
||||
\subsection{Detect corrupt exits and other servers}
|
||||
With the success of our network, we've attracted servers in many locations,
|
||||
operated by many kinds of people. Unfortunately, some of these locations
|
||||
have compromised or defective networks, and some of these people are
|
||||
untrustworthy or incompetent. Our current design relies on authority
|
||||
administrators to identify bad nodes and mark them as nonfunctioning. We
|
||||
should {\bf automate the process of identifying malfunctioning nodes} as
|
||||
follows:
|
||||
|
||||
We should create a generic {\bf feedback mechanism for add-on tools} like
|
||||
Mike Perry's ``Snakes on a Tor'' to report failing nodes to authorities.
|
||||
\plan{Do in 2006; 1-2 weeks.}
|
||||
|
||||
We should write tools to {\bf detect more kinds of innocent node failure},
|
||||
such as nodes whose network providers intercept SSL, nodes whose network
|
||||
providers censor popular websites, and so on. We should also try to detect
|
||||
{\bf routers that snoop traffic}; we could do this by launching connections
|
||||
to throwaway accounts, and seeing which accounts get used.\plan{Do in 2007;
|
||||
ask Mike Perry if he's interested. 4-6 weeks.}
|
||||
|
||||
We should add {\bf an efficient way for authorities to mark a set of servers
|
||||
as probably collaborating} though not necessarily otherwise dishonest.
|
||||
This happens when an administrator starts multiple routers, but doesn't mark
|
||||
them as belonging to the same family.\plan{Do during v2.1 directory protocol
|
||||
redesign; 1-2 weeks to implement.}
|
||||
|
||||
To avoid attacks where an adversary claims good performance in order to
|
||||
attract traffic, we should {\bf have authorities measure node performance}
|
||||
(including stability and bandwidth) themselves, and not simply believe what
|
||||
they're told. We also measure stability by tracking MTBF. Measuring
|
||||
bandwidth will be tricky, since it's hard to distinguish between a server with
|
||||
low capacity, and a high-capacity server with most of its capacity in
|
||||
use. See also Nikita's NDSS 2008 paper.\plan{Do it if we can interest
|
||||
a grad student.}
|
||||
|
||||
{\bf Operating a directory authority should be easier.} We rely on authority
|
||||
operators to keep the network running well, but right now their job involves
|
||||
too much busywork and administrative overhead. A better interface for them
|
||||
to use could free their time to work on exception cases rather than on
|
||||
adding named nodes to the network.\plan{Do in 2007; 4-5 weeks.}
|
||||
|
||||
\subsection{Protocol security}
|
||||
|
||||
In addition to other protocol changes discussed above,
|
||||
% And should we move some of them down here? -NM
|
||||
we should add {\bf hooks for denial-of-service resistance}; we have some
|
||||
preliminary designs, but we shouldn't postpone them until we really need them.
|
||||
If somebody tries a DDoS attack against the Tor network, we won't want to
|
||||
wait for all the servers and clients to upgrade to a new
|
||||
version.\plan{Research project; do this in 2007 if funded.}
|
||||
|
||||
\section{Development infrastructure}
|
||||
|
||||
\subsection{Build farm}
|
||||
We've begun to deploy a cross-platform distributed build farm of hosts
|
||||
that build and test the Tor source every time it changes in our development
|
||||
repository.
|
||||
|
||||
We need to {\bf get more participants}, so that we can test a larger variety
|
||||
of platforms. (Previously, we've only found out when our code had broken on
|
||||
obscure platforms when somebody got around to building it.)
|
||||
|
||||
We need also to {\bf add our dependencies} to the build farm, so that we can
|
||||
ensure that libraries we need (especially libevent) do not stop working on
|
||||
any important platform between one release and the next.
|
||||
|
||||
\plan{This is ongoing as more buildbots arrive.}
|
||||
|
||||
\subsection{Improved testing harness}
|
||||
Currently, our {\bf unit tests} cover only about 20\% of the code base. This
|
||||
is uncomfortably low; we should write more and switch to a more flexible
|
||||
testing framework.\plan{Ongoing basis, time permitting.}
|
||||
|
||||
We should also write flexible {\bf automated single-host deployment tests} so
|
||||
we can more easily verify that the current codebase works with the
|
||||
network.\plan{Worthwhile in 2007; would save lots of time. 2-4 weeks.}
|
||||
|
||||
We should build automated {\bf stress testing} frameworks so we can see which
|
||||
realistic loads cause Tor to perform badly, and regularly profile Tor against
|
||||
these loads. This would give us {\it in vitro} performance values to
|
||||
supplement our deployment experience.\plan{Worthwhile in 2007; 2-6 weeks.}
|
||||
|
||||
We should improve our memory profiling code.\plan{...}
|
||||
|
||||
|
||||
\subsection{Centralized build system}
|
||||
We currently rely on a separate packager to maintain the packaging system and
|
||||
to build Tor on each platform for which we distribute binaries. Separate
|
||||
package maintainers is sensible, but separate package builders has meant
|
||||
long turnaround times between source releases and package releases. We
|
||||
should create the necessary infrastructure for us to produce binaries for all
|
||||
major packages within an hour or so of source release.\plan{We should
|
||||
brainstorm this at least in 2007.}
|
||||
|
||||
\subsection{Improved metrics}
|
||||
We need a way to {\bf measure the network's health, capacity, and degree of
|
||||
utilization}. Our current means for doing this are ad hoc and not
|
||||
completely accurate
|
||||
|
||||
We need better ways to {\bf tell which countries are users are coming from,
|
||||
and how many there are}. A good perspective of the network helps us
|
||||
allocate resources and identify trouble spots, but our current approaches
|
||||
will work less and less well as we make it harder for adversaries to
|
||||
enumerate users. We'll probably want to shift to a smarter, statistical
|
||||
approach rather than our current ``count and extrapolate'' method.
|
||||
|
||||
\plan{All of this in 2007 if funded; 4-8 weeks}
|
||||
|
||||
% \tmp{We'd like to know how much of the network is getting used.}
|
||||
% I think this is covered above -NM
|
||||
|
||||
\subsection{Controller library}
|
||||
We've done lots of design and development on our controller interface, which
|
||||
allows UI applications and other tools to interact with Tor. We could
|
||||
encourage the development of more such tools by releasing a {\bf
|
||||
general-purpose controller library}, ideally with API support for several
|
||||
popular programming languages.\plan{2006 or 2007; 1-2 weeks.}
|
||||
|
||||
\section{User experience}
|
||||
|
||||
\subsection{Get blocked less, get blocked less broadly}
|
||||
Right now, some services block connections from the Tor network because
|
||||
they don't have a better
|
||||
way to keep vandals from abusing them than blocking IP addresses associated
|
||||
with vandalism. Our approach so far has been to educate them about better
|
||||
solutions that currently exist, but we should also {\bf create better
|
||||
solutions for limiting vandalism by anonymous users} like credential and
|
||||
blind-signature based implementations, and encourage their use. Other
|
||||
promising starting points including writing a patch and explanation for
|
||||
Wikipedia, and helping Freenode to document, maintain, and expand its
|
||||
current Tor-friendly position.\plan{Do a writeup here in 2007; 1-2 weeks.}
|
||||
|
||||
Those who do block Tor users also block overbroadly, sometimes blacklisting
|
||||
operators of Tor servers that do not permit exit to their services. We could
|
||||
obviate innocent reasons for doing so by designing a {\bf narrowly-targeted Tor
|
||||
RBL service} so that those who wanted to overblock Tor could no longer
|
||||
plead incompetence.\plan{Possibly in 2007 if we decide it's a good idea; 3
|
||||
weeks.}
|
||||
|
||||
\subsection{All-in-one bundle}
|
||||
We need a well-tested, well-documented bundle of Tor and supporting
|
||||
applications configured to use it correctly. We have an initial
|
||||
implementation well under way, but it will need additional work in
|
||||
identifying requisite Firefox extensions, identifying security threats,
|
||||
improving user experience, and so on. This will need significantly more work
|
||||
before it's ready for a general public release.
|
||||
|
||||
\subsection{LiveCD Tor}
|
||||
We need a nice bootable livecd containing a minimal OS and a few applications
|
||||
configured to use it correctly. The Anonym.OS project demonstrated that this
|
||||
is quite feasible, but their project is not currently maintained.
|
||||
|
||||
\subsection{A Tor client in a VM}
|
||||
\tmp{a.k.a JanusVM} which is quite related to the firewall-level deployment
|
||||
section below. JanusVM is a Linux kernel running in VMWare. It gets an IP
|
||||
address from the network, and serves as a DHCP server for its host Windows
|
||||
machine. It intercepts all outgoing traffic and redirects it into Privoxy,
|
||||
Tor, etc. This Linux-in-Windows approach may help us with scalability in
|
||||
the short term, and it may also be a good long-term solution rather than
|
||||
accepting all security risks in Windows.
|
||||
|
||||
%\subsection{Interface improvements}
|
||||
%\tmp{Allow controllers to manipulate server status.}
|
||||
% (Why is this in the User Experience section?) -RD
|
||||
% I think it's better left to a generic ``make controller iface better'' item.
|
||||
|
||||
\subsection{Firewall-level deployment}
|
||||
Another useful deployment mode for some users is using {\bf Tor in a firewall
|
||||
configuration}, and directing all their traffic through Tor. This can be a
|
||||
little tricky to set up currently, but it's an effective way to make sure no
|
||||
traffic leaves the host un-anonymized. To achieve this, we need to {\bf
|
||||
improve and port our new TransPort} feature which allows Tor to be used
|
||||
without SOCKS support; to {\bf add an anonymizing DNS proxy} feature to Tor;
|
||||
and to {\bf construct a recommended set of firewall configurations} to redirect
|
||||
traffic to Tor.
|
||||
|
||||
This is an area where {\bf deployment via a livecd}, or an installation
|
||||
targeted at specialized home routing hardware, could be useful.
|
||||
|
||||
\subsection{Assess software and configurations for anonymity risks}
|
||||
Right now, users and packagers are more or less on their own when selecting
|
||||
Firefox extensions. We should {\bf assemble a recommended list of browser
|
||||
extensions} through experiment, and include this in the application bundles
|
||||
we distribute.
|
||||
|
||||
We should also describe {\bf best practices for using Tor with each class of
|
||||
application}. For example, Ethan Zuckerman has written a detailed
|
||||
tutorial on how to use Tor, Firefox, GMail, and Wordpress to blog with
|
||||
improved safety. There are many other cases on the Internet where anonymity
|
||||
would be helpful, and there are a lot of ways to screw up using Tor.
|
||||
|
||||
The Foxtor and Torbutton extensions serve similar purposes; we should pick a
|
||||
favorite, and merge in the useful features of the other.
|
||||
|
||||
%\tmp{clean up our own bundled software:
|
||||
%E.g. Merge the good features of Foxtor into Torbutton}
|
||||
%
|
||||
% What else did you have in mind? -NM
|
||||
|
||||
\subsection{Localization}
|
||||
Right now, most of our user-facing code is internationalized. We need to
|
||||
internationalize the last few hold-outs (like the Tor expert installer), and get
|
||||
more translations for the parts that are already internationalized.
|
||||
|
||||
Also, we should look into a {\bf unified translator's solution}. Currently,
|
||||
since different tools have been internationalized using the
|
||||
framework-appropriate method, different tools require translators to localize
|
||||
them via different interfaces. Inasmuch as possible, we should make
|
||||
translators only need to use a single tool to translate the whole Tor suite.
|
||||
|
||||
\section{Support}
|
||||
|
||||
It would be nice to set up some {\bf user support infrastructure} and
|
||||
{\bf contributor support infrastructure}, especially focusing on server
|
||||
operators and on coordinating volunteers.
|
||||
|
||||
This includes intuitive and easy ticket systems for bug reports and
|
||||
feature suggestions (not just mailing lists with a half dozen people
|
||||
and no clear roles for who answers what), but it also includes a more
|
||||
personalized and efficient framework for interaction so we keep the
|
||||
attention and interest of the contributors, and so we make them feel
|
||||
helpful and wanted.
|
||||
|
||||
\section{Documentation}
|
||||
|
||||
\subsection{Unified documentation scheme}
|
||||
|
||||
We need to {\bf inventory our documentation.} Our documentation so far has
|
||||
been mostly produced on an {\it ad hoc} basis, in response to particular
|
||||
needs and requests. We should figure out what documentation we have, which of
|
||||
it (if any) should get priority, and whether we can't put it all into a
|
||||
single format.
|
||||
|
||||
We could {\bf unify the docs} into a single book-like thing. This will also
|
||||
help us identify what sections of the ``book'' are missing.
|
||||
|
||||
\subsection{Missing technical documentation}
|
||||
|
||||
We should {\bf revise our design paper} to reflect the new decisions and
|
||||
research we've made since it was published in 2004. This will help other
|
||||
researchers evaluate and suggest improvements to Tor's current design.
|
||||
|
||||
Other projects sometimes implement the client side of our protocol. We
|
||||
encourage this, but we should write {\bf a document about how to avoid
|
||||
excessive resource use}, so we don't need to worry that they will do so
|
||||
without regard to the effect of their choices on server resources.
|
||||
|
||||
\subsection{Missing user documentation}
|
||||
|
||||
Our documentation falls into two broad categories: some is `discoursive' and
|
||||
explains in detail why users should take certain actions, and other
|
||||
documentation is `comprehensive' and describes all of Tor's features. Right
|
||||
now, we have no document that is both deep, readable, and thorough. We
|
||||
should correct this by identifying missing spots in our design.
|
||||
|
||||
\bibliographystyle{plain} \bibliography{tor-design}
|
||||
|
||||
\end{document}
|
||||
|
||||
@ -1,175 +0,0 @@
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%deffont "standard" xfont "comic sans ms-medium-r"
|
||||
%%deffont "thick" xfont "arial black-medium-r"
|
||||
%%deffont "typewriter" xfont "courier new-bold-r"
|
||||
%%deffont "type2writer" xfont "arial narrow-bold-r"
|
||||
%%deffont "standard" tfont "standard.ttf", tmfont "kochi-mincho.ttf"
|
||||
%%deffont "thick" tfont "thick.ttf", tmfont "goth.ttf"
|
||||
%%deffont "typewriter" tfont "typewriter.ttf", tmfont "goth.ttf"
|
||||
%deffont "standard" xfont "helvetica-medium-r", tfont "arial.ttf", tmfont "times.ttf"
|
||||
%deffont "thick" xfont "helvetica-bold-r", tfont "arialbd.ttf", tmfont "hoso6.ttf"
|
||||
%deffont "italic" xfont "helvetica-italic-r", tfont "ariali.ttf", tmfont "hoso6.ttf"
|
||||
%deffont "typewriter" xfont "courier-medium-r", tfont "typewriter.ttf", tmfont "hoso6.ttf"
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%
|
||||
%% Default settings per each line numbers.
|
||||
%%
|
||||
%default 1 leftfill, size 8, fore "black", back "white", font "thick", hgap 1
|
||||
%default 2 size 8, vgap 10, prefix " ", ccolor "black"
|
||||
%default 3 size 6, bar "gray70", vgap 0
|
||||
%default 4 size 6, fore "black", vgap 0, prefix " ", font "standard"
|
||||
%%
|
||||
%%default 1 area 90 90, leftfill, size 9, fore "yellow", back "blue", font "thick"
|
||||
%%default 2 size 9, vgap 10, prefix " "
|
||||
%%default 3 size 7, bar "gray70", vgap 10
|
||||
%%default 4 size 7, vgap 30, prefix " ", font "standard"
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%
|
||||
%% Default settings that are applied to TAB-indented lines.
|
||||
%%
|
||||
%tab 1 size 5, vgap 40, prefix " ", icon arc "red" 50
|
||||
%tab 2 size 4, vgap 35, prefix " ", icon delta3 "blue" 40
|
||||
%tab 3 size 3, vgap 35, prefix " ", icon dia "DarkViolet" 40
|
||||
%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
%nodefault
|
||||
%center, size 9, font "thick", back "white", fore "black"
|
||||
|
||||
|
||||
|
||||
Tor:
|
||||
%size 8
|
||||
Next-generation Onion Routing
|
||||
|
||||
|
||||
%size 7
|
||||
Roger Dingledine
|
||||
Nick Mathewson
|
||||
Paul Syverson
|
||||
|
||||
%%The Free Haven Project
|
||||
%%%font "typewriter", fore "blue"
|
||||
%%http://freehaven.net/
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Low-latency anonymity system
|
||||
|
||||
%leftfill
|
||||
Deployed: 19 nodes, hundreds of users (?)
|
||||
|
||||
Many improvements on earlier design
|
||||
|
||||
Free software -- available source code
|
||||
|
||||
Design is not covered by earlier onion routing
|
||||
patent
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Perfect forward secrecy
|
||||
|
||||
|
||||
Telescoping circuit
|
||||
|
||||
negotiates keys at each hop
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%page
|
||||
%%
|
||||
%%Separation from "protocol cleaning"
|
||||
%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
No mixing, padding, traffic shaping (yet)
|
||||
|
||||
|
||||
Please show us they're worth the usability tradeoff
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%page
|
||||
%%
|
||||
%%Many TCP streams can share one circuit
|
||||
%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Congestion control
|
||||
|
||||
|
||||
Simple rate limiting
|
||||
|
||||
Plus have to keep internal nodes from overflowing
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Directory servers
|
||||
|
||||
|
||||
Approve new servers
|
||||
|
||||
Tell clients who's up right now
|
||||
|
||||
plus their keys, location, etc
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Variable exit policies
|
||||
|
||||
|
||||
Each server allows different outgoing connections
|
||||
|
||||
E.g. no servers allow outgoing mail currently
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
End-to-end integrity checking
|
||||
|
||||
|
||||
In previous onion routing, an insider could change
|
||||
the text being transmitted:
|
||||
|
||||
"dir" => "rm *"
|
||||
|
||||
Even an external adversary could do this!
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Rendezvous points
|
||||
|
||||
|
||||
allow hidden services
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
Differences / limitations
|
||||
|
||||
|
||||
We're TCP-only, not all IP (but we're user-space and very portable)
|
||||
|
||||
Not peer-to-peer
|
||||
|
||||
No protocol normalization
|
||||
|
||||
%%Not unobservable
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%page
|
||||
|
||||
We have working code
|
||||
|
||||
|
||||
Plus a design document,
|
||||
and a byte-level specification
|
||||
|
||||
%size 9
|
||||
http://freehaven.net/tor/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user