i2p.www/pages/how_networkcomparisons.html

<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>Morphmix and Tarzan</li>
<li>TOR / Onion Routing</li>
<li>Mixminion / Mixmaster</li>
<li>Freenet</li>
<li>JAP</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 accomplishs 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>
<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>
<p>(Original image at <a href="http://dev.i2p.net/~jrandom/wiki/comparison.png">
http://dev.i2p.net/~jrandom/wiki/comparison.png</a>)</p>

<h2>TOR / Onion Routing</h2>
<i><a href="http://freehaven.net/tor/">[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 now
supports hidden services).  In addition, these networks 
take 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 following is a more detailed comparison of TOR and
I2P, but in it, one of the really cool features of TOR is 
overlooked - the ability to outproxy onto the normal internet.
That feature is a very useful one, and relevant for many 
situations.</p>

<p>However, the 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, most people don't need to worry about those 
situations, as they are outside their threat model.  It
is, also, outside I2P's 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>

<h3>Benefits of TOR over I2P</h3>
<ul>
 <li>More efficient w/ 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>Fully distributed and self organizing</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>resiliance 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>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>Java, not C (ewww)</li>
</ul>

<h3>Other 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 discernable
     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>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.  
As such, generic anonymous communication over it requires the use of the global
blackboard model - storing data somewhere that the recipient will then check 
for a message.  Freenet also does not support the concept of user defined delays -
it stores and fetches data as quickly as it can, rather than queueing up, pooling,
delaying, and mixing the data, leaving a hole with regards to long term intersection
attacks.  In addition, there seem to be some performance issues that can arguably
be attributed to the global blackboard model which will likely rule out interactive
low latency communication.</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>