359 lines
16 KiB
HTML
359 lines
16 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Compared to Other Anonymous Networks{% endblock %}
|
|
{% block content %}<p>There are a great many other applications and projects working on anonymous
|
|
communication and I2P has been inspired by much of their efforts. This is not
|
|
a comprehensive list of anonymity resources - both freehaven's
|
|
<a href="http://freehaven.net/anonbib/topic.html">Anonymity Bibliography</a>
|
|
and GNUnet's <a href="http://www.ovmj.org/GNUnet/links.php3">related projects</a>
|
|
serve that purpose well. That said, a few systems stand out for further
|
|
comparison:</p>
|
|
<ul>
|
|
<li>Tor / Onion Routing</li>
|
|
<li>Morphmix and Tarzan</li>
|
|
<li>Mixminion / Mixmaster</li>
|
|
<li>Freenet</li>
|
|
<li>JAP</li>
|
|
<li>MUTE / AntsP2P</li>
|
|
</ul>
|
|
|
|
<p>The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.</p>
|
|
|
|
<h2>Tor / Onion Routing</h2>
|
|
<i><a href="http://www.torproject.org/">[Tor]</a>
|
|
<a href="http://www.onion-router.net">[Onion Routing]</a></i>
|
|
<p>Tor and Onion Routing are both anonymizing proxy networks,
|
|
allowing people to tunnel out through their low latency mix
|
|
network. The two primary differences between Tor /
|
|
Onion-Routing and I2P are again related to differences in
|
|
the threat model and the out-proxy design (though Tor
|
|
supports hidden services as well). In addition, Tor
|
|
takes the directory-based approach - providing a
|
|
centralized point to manage the overall 'view' of the
|
|
network, as well as gather and report statistics, as
|
|
opposed to I2P's distributed <a href="how_networkdatabase">network
|
|
database</a> and <a href="how_peerselection">peer selection</a>.</p>
|
|
|
|
<p>The I2P/Tor outproxy functionality does have a few
|
|
substantial weaknesses against certain attackers -
|
|
once the communication leaves the mixnet, global passive
|
|
adversaries can more easily mount traffic analysis. In
|
|
addition, the outproxies have access to the cleartext
|
|
of the data transferred in both directions, and
|
|
outproxies are prone to abuse, along with all of the
|
|
other security issues we've come to know and love with
|
|
normal Internet traffic.</p>
|
|
|
|
<p>However, many people don't need to worry about those
|
|
situations, as they are outside their threat model. It
|
|
is, also, outside I2P's (formal) functional scope (if people want
|
|
to build outproxy functionality on top of an anonymous
|
|
communication layer, they can). In fact, some I2P users
|
|
currently take advantage of Tor to outproxy.</p>
|
|
|
|
<p>See also the
|
|
<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ComparisonI2P">the Tor FAQ</a>
|
|
for a Tor/I2P comparison from the Tor perspective.</p>
|
|
|
|
<h3>Comparison of Tor and I2P Terminology</h3>
|
|
While Tor and I2P are similar in many ways, much of the terminology is different.
|
|
<table>
|
|
<tr><th align="left">Tor<th align="left">I2P
|
|
<tr><td>Cell<td>Message
|
|
<tr><td>Client<td>Router or Client
|
|
<tr><td>Circuit<td>Tunnel
|
|
<tr><td>Directory<td>NetDb
|
|
<tr><td>Directory Server<td>Floodfill Router
|
|
<tr><td>Entry Guards<td>Fast Peers
|
|
<tr><td>Entry Node<td>Inproxy
|
|
<tr><td>Exit Node<td>Outproxy
|
|
<tr><td>Hidden Service<td>Eepsite or Destination
|
|
<tr><td>Hidden Service Descriptor<td>LeaseSet
|
|
<tr><td>Introduction point<td>Inbound Gateway
|
|
<tr><td>Node<td>Router
|
|
<tr><td>Onion Proxy<td>I2PTunnel Client (more or less)
|
|
<tr><td>Relay<td>Router
|
|
<tr><td>Rendezvous Point<td>somewhat like Inbound Gateway + Outbound Endpoint
|
|
<tr><td>Router Descriptor<td>RouterInfo
|
|
<tr><td>Server<td>Router
|
|
</table>
|
|
|
|
<h3>Benefits of Tor over I2P</h3>
|
|
<ul>
|
|
<li>Much bigger user base; much more visibility in the academic and hacker communities; benefits from
|
|
formal studies of anonymity, resistance, and performance;
|
|
has a non-anonymous, visible, university-based leader</li>
|
|
<li>Has already solved some scaling issues I2P has yet to address</li>
|
|
<li>Has significant funding</li>
|
|
<li>Has more developers, including several that are funded</li>
|
|
<li>More resistant to state-level blocking due to TLS transport layer and bridges
|
|
(I2P has proposals for "full restricted routes" but these are not yet implemented)</li>
|
|
<li>Big enough that it has had to adapt to blocking and DOS attempts<li>
|
|
<li>Designed and optimized for exit traffic, with a large number of exit nodes</li>
|
|
<li>Better documentation, has formal papers and specifications, better website, many more translations</li>
|
|
<li>More efficient with memory usage</li>
|
|
<li>Tor client nodes have very low bandwidth overhead</li>
|
|
<li>Centralized control reduces the complexity at each
|
|
node and can efficiently address Sybil attacks</li>
|
|
<li>A core of high capacity nodes provides higher
|
|
throughput and lower latency</li>
|
|
<li>C, not Java (ewww)</li>
|
|
</ul>
|
|
|
|
<h3>Benefits of I2P over Tor</h3>
|
|
<ul>
|
|
<li>Designed and optimized for hidden services, which are much faster than in Tor</li>
|
|
<li>Fully distributed and self organizing</li>
|
|
<li>Peers are selected by continuously profiling and ranking performance,
|
|
rather than trusting claimed capacity</li>
|
|
<li>Floodfill peers ("directory servers") are varying and untrusted,
|
|
rather than hardcoded</li>
|
|
<li>Small enough that it hasn't been blocked or DOSed much, or at all<li>
|
|
<li>Peer-to-peer friendly<li>
|
|
<li>Packet switched instead of circuit switched
|
|
<ul>
|
|
<li>implicit transparent load balancing of messages
|
|
across multiple peers, rather than a single path</li>
|
|
<li>resilience vs. failures by running multiple
|
|
tunnels in parallel, plus rotating tunnels</li>
|
|
<li>scale each client's connections at O(1) instead
|
|
of O(N) (Alice has e.g. 2 inbound tunnels that are
|
|
used by all of the peers Alice is talking with,
|
|
rather than a circuit for each)</li>
|
|
</ul></li>
|
|
<li>Unidirectional tunnels instead of bidirectional
|
|
circuits, doubling the number of nodes a peer has to
|
|
compromise to get the same information.</li>
|
|
<li>Protection against detecting client activity, even
|
|
when an attacker is participating in the tunnel, as
|
|
tunnels are used for more than simply passing end
|
|
to end messages (e.g. netDb, tunnel management,
|
|
tunnel testing)</li>
|
|
<li>Tunnels in I2P are short lived, decreasing the number
|
|
of samples that an attacker can use to mount an
|
|
active attack with, unlike circuits in Tor, which are
|
|
typically long lived.</li>
|
|
<li>I2P APIs are designed specifically for anonymity and
|
|
security, while SOCKS is designed for functionality.</li>
|
|
<li>Essentially all peers participate in routing for others</li>
|
|
<li>The bandwidth overhead of being a full peer is low,
|
|
while in Tor, while client nodes don't require much
|
|
bandwidth, they don't fully participate in the mixnet.</li>
|
|
<li>Integrated automatic update mechanism</li>
|
|
<li>Both TCP and UDP transports</li>
|
|
<li>Java, not C (ewww)</li>
|
|
</ul>
|
|
|
|
<h3>Other potential benefits of I2P but not yet implemented</h3>
|
|
<ul>
|
|
<li>Defense vs. message count analysis by garlic wrapping
|
|
multiple messages</li>
|
|
<li>Defense vs. long term intersection by adding delays
|
|
at various hops (where the delays are not discernible
|
|
by other hops)</li>
|
|
<li>Various mixing strategies at the tunnel level (e.g.
|
|
create a tunnel that will handle 500 messages / minute,
|
|
where the endpoint will inject dummy messages if there
|
|
are insufficient messages, etc)</li>
|
|
</ul>
|
|
|
|
<h2>Morphmix and Tarzan</h2>
|
|
<i><a href="http://www.tik.ee.ethz.ch/~morphmix/">[Morphmix]</a>
|
|
<a href="http://www.pdos.lcs.mit.edu/tarzan/">[Tarzan]</a></i>
|
|
|
|
<p>Morphmix and Tarzan are both fully distributed, peer to peer networks of
|
|
anonymizing proxies, allowing people to tunnel out through the low latency
|
|
mix network. Morphmix includes some very interesting collusion detection
|
|
algorithms and Sybil defenses, while Tarzan makes use of the scarcity of IP
|
|
addresses to accomplish the same. The two primary differences between
|
|
these systems and I2P are related to I2P's <a href="how_threatmodel">threat model</a>
|
|
and their out-proxy design (as opposed to providing both sender and receiver
|
|
anonymity). There is source code available to both systems, but we are not aware
|
|
of their use outside of academic environments.</p>
|
|
|
|
<!--
|
|
Table needs correction, disabled for now.
|
|
|
|
Comments from arma on 2010-09-14 in #nottor:
|
|
You say "maybe" under the tarzan column, because tarzan says "we hope to get this level of protection, but it is an open research question how one would get it"
|
|
then i2p says "no, all solved, we solve that one" in its column. which either means you've got a brilliant new design but have failed to articulate it or publish about it, or you are misleading people.
|
|
this table has been around, and misleading people and frustrating me, for something like 8 or 10 years now.
|
|
the fundamental problem is that for the projects that exist, you put down their current levels of protection in the table (fine), but for i2p you put down your desired level of protection (not fine)
|
|
End of comments
|
|
|
|
<p>Stealing quite directly from the Tarzan paper, the following includes a quick
|
|
comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:</p>
|
|
|
|
<table>
|
|
<tr>
|
|
<td style="width: 19%;"></td>
|
|
<td style="width: 27%;" colspan="4">Bad first relay/router</td>
|
|
<td style="width: 27%;" colspan="4">Bad intermediate relay/router</td>
|
|
<td style="width: 27%;" colspan="4">Bad last relay/router</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Information exposed</td>
|
|
<td><b>OR</b></td>
|
|
<td><b>Crowds</b></td>
|
|
<td><b>Tarzan</b></td>
|
|
<td><b>I2P</b></td>
|
|
|
|
<td><b>OR</b></td>
|
|
<td><b>Crowds</b></td>
|
|
<td><b>Tarzan</b></td>
|
|
<td><b>I2P</b></td>
|
|
|
|
<td><b>OR</b></td>
|
|
<td><b>Crowds</b></td>
|
|
<td><b>Tarzan</b></td>
|
|
<td><b>I2P</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Sender activity</td>
|
|
<td>Yes</td>
|
|
<td>Maybe</td>
|
|
<td>Maybe</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td>Maybe</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Recipient activity</td>
|
|
<td>No</td>
|
|
<td>Yes</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>No</td>
|
|
<td>Yes</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>Yes</td>
|
|
<td>Yes</td>
|
|
<td>Yes</td>
|
|
<td><b>No</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Sender content</td>
|
|
<td>No</td>
|
|
<td>Maybe</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Recipient content</td>
|
|
<td>No</td>
|
|
<td>Yes</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>No</td>
|
|
<td>Yes</td>
|
|
<td>No</td>
|
|
<td><b>No</b></td>
|
|
|
|
<td>Yes</td>
|
|
<td>Yes</td>
|
|
<td>Yes</td>
|
|
<td><b>No</b></td>
|
|
</tr>
|
|
</table>
|
|
-->
|
|
|
|
<h2>Mixminion / Mixmaster</h2>
|
|
<i><a href="http://mixminion.net/">[Mixminion]</a>
|
|
<a href="http://mixmaster.sourceforge.net/">[Mixmaster]</a></i>
|
|
|
|
<p>Mixminion and Mixmaster are networks to support anonymous email against a very
|
|
powerful adversary. I2P aims to provide an adequate means to meet their threat
|
|
model as we reach I2P 3.0 along side the needs of low latency users, providing
|
|
a significantly larger anonymity set. As with Tor and Onion Routing above,
|
|
both Mixminion and Mixmaster take the directory based approach as well.</p>
|
|
|
|
<h2>Freenet</h2>
|
|
<i><a href="http://freenetproject.org/">[Freenet]</a></i>
|
|
|
|
<p>Freenet is a fully distributed, peer to peer anonymous publishing network, offering
|
|
secure ways to store data, as well as some approaches attempting to address the loads
|
|
of a flash flood. While Freenet is designed as a distributed data store, people have
|
|
built applications on top of it to do more generic anonymous communication, such as
|
|
static websites and message boards.</p>
|
|
|
|
<p>Compared to I2P, Freenet offers some substantial benefits - it is a distributed data
|
|
store, while I2P is not, allowing people to retrieve the content published by others
|
|
even when the publisher is no longer online. In addition, it should be able to
|
|
distribute popular data fairly efficiently. I2P itself does not and will not provide
|
|
this functionality. On the other hand, there is overlap for users who simply want to
|
|
communicate with each other anonymously through websites, message boards, file sharing
|
|
programs, etc. There have also been some developers working on a distributed data
|
|
store to run on top of I2P, but those are not ready for general use yet.</p>
|
|
|
|
<p>However, even ignoring any implementations issues, there are some serious concerns
|
|
about Freenet's algorithms from both a scalability and anonymity perspective, owing
|
|
largely to Freenet's heuristic driven routing. The interactions of various techniques
|
|
certainly may successfully deter various attacks, and perhaps some aspects of the
|
|
routing algorithms will provide the hoped for scalability. Unfortunately, not much
|
|
analysis of the algorithms involved has resulted in positive results, but there is still
|
|
hope. At the very least, Freenet does provide substantial anonymity against an attacker
|
|
who does not have the resources necessary to analyze it further.</p>
|
|
|
|
<h2>JAP</h2>
|
|
<i><a href="http://anon.inf.tu-dresden.de/index_en.html">[JAP]</a></i>
|
|
|
|
<p>JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests,
|
|
and as such it has a few centralized nodes (participants in the cascade) that blend
|
|
and mix requests from clients through the sequence of nodes (the cascade) before
|
|
proxying out onto the web. The scope, threat model, and security is substantially
|
|
different from I2P, but for those who don't require significant anonymity but still
|
|
are not satisfied with an Anonymizer-like service, JAP is worth reviewing. One
|
|
caution to note is that anyone under the jurisdiction of the German courts may want
|
|
to take care, as the German Federal Bureau of Criminal Investigation (FBCI) has has
|
|
successfully mounted an
|
|
<a href="http://www.datenschutzzentrum.de/material/themen/presse/anonip3_e.htm">attack</a>
|
|
on the network. Even though the method of this attack was later found to be illegal
|
|
in the German courts, the fact that the data was successfully collected is the
|
|
concern. Courts change their minds based upon circumstance, and this is evidence that
|
|
if a government body or intelligence agency wanted to, they could gather the data, even
|
|
if it may be found inadmissible in some courts later)</p>
|
|
|
|
<h2>MUTE / AntsP2P</h2>
|
|
<i><a href="http://mute-net.sourceforge.net/">[MUTE]</a>
|
|
<a href="http://www.myjavaserver.com/~gwren/home.jsp?page=custom&xmlName=ants">[AntsP2P]</a></i>
|
|
|
|
<p>Both of these systems work through the same basic
|
|
<a href="http://citeseer.ist.psu.edu/57701.html">antnet</a> routing, providing some degree of
|
|
anonymity based on the threat model of providing plausible deniability against a simple
|
|
non-colluding adversary. With the antnet routing, they first either do a random walk or a
|
|
broadcast search to find some peer with the data or identity desired, and then use a feedback
|
|
algorithm to optimize that found path. This works well for applications that merely want to know
|
|
what other people around them have to offer - "How are y'all doing" vs. "Hey Alice, how are you" -
|
|
you basically get a local cluster of nodes that can share files with and maintain some degree of
|
|
anonymity (though you don't have much control over who is in that group of peers).</p>
|
|
|
|
<p>However, the algorithm does not scale well at all - if the application wants to speak with a
|
|
particular peer it ends up doing a broadcast search or random walk (though if they are lucky enough
|
|
for that to succeed, the antnet routing should optimize that found connection). This means that
|
|
while these networks can work great at small scales, they are not suitable for large networks where
|
|
someone wants to get in touch with another specific peer. That does not mean that there is no
|
|
value in these systems, just that their applicability is limited to situations where their
|
|
particular issues can be addressed.</p>
|
|
{% endblock %}
|