nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 13:13:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

Edits to section 9

Browse Source 
svn:r752
This commit is contained in:
Nick Mathewson 2003-11-04 08:30:10 +00:00
parent 23fabf60e5
commit f081a7a41f
1 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
doc/tor-design.tex
View File

@ -1374,11 +1374,6 @@ acknowledge his existence.
% enable us to accept a lot more ORs than if we continue to
% require 10mbit connections for all ORs. -RD
% XXX In sec9, we should note that we are currently
% working with the designers of MorphMix to render our two systems
% interoperable. So far, this seems to be relatively straightforward.
% Interoperability will allow testing and direct comparison of the two
% rather different designs.
Below we summarize a variety of attacks, and discuss how well our
design withstands them.
@ -1885,14 +1880,14 @@ experience would be helpful in learning the relative importance of
these bottlenecks.
\emph{Cover traffic:} Currently we avoid cover traffic because
of its clear costs in performance and bandwidth, and because its
whereas its costs in performance and bandwidth are clear, and because its
security benefits are not well understood. With more research
\cite{SS03,defensive-dropping}, the price/value ratio may change,
\cite{SS03,defensive-dropping}, this price/value ratio may change,
both for link-level cover traffic and also long-range cover traffic.
\emph{Better directory distribution:} Even with the threshold
directory agreement algorithm described in Section~\ref{subsec:dirservers},
the directory servers are still trust bottlenecks. We must find more
directory distribution is still performance-critical. We must find more
decentralized yet practical ways to distribute up-to-date snapshots of
network status without introducing new attacks. Also, directory
retrieval presents a scaling problem, since clients currently
@ -1908,14 +1903,21 @@ implemented. While doing so we are likely to encounter additional
issues that must be resolved, both in terms of usability and anonymity.
\emph{Further specification review:} Although we have a public,
byte-level specification for the Tor protocols, this protocol has
byte-level specification for the Tor protocols, this document has
not received extensive external review. We hope that as Tor
becomes more widely deployed, more people will become interested in
examining our specification.
becomes more widely deployed, more people will examine its
specification.
\emph{Multisystem interoperability:} We are currently working with the
designers of MorphMix to make the common elements of our two systems
share a common specification and implementation. So far, this seems
to be relatively straightforward. Interoperability will allow testing
and direct comparison of the two designs for trust and scalability.
% XXXX Bandwidth classes.
\emph{Wider-scale deployment:} The original goal of Tor was to
gain experience in deploying an anonymizing overlay network, and
learn from having actual users. We are now at the point in design
learn from having actual users. We are now at a point in design
and development where we can start deploying a wider network. Once
we have many actual users, we will doubtlessly be better
able to evaluate some of our design decisions, including our
@ -1923,7 +1925,6 @@ robustness/latency trade-offs, our performance trade-offs (including
cell size), our abuse-prevention mechanisms, and
our overall usability.
% XXX large and small cells on same network.
% XXX work with morphmix spec
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%