Tor / Onion Routing

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 network database and peer selection.

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.

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.

Comparison of Tor and I2P Terminology

While Tor and I2P are similar in many ways, much of the terminology is different.

Tor 相对 I2P 的优势

• 大许多的用户群；在学术和黑客群体中得到较多关注； 基于正式研究的匿名性、抵抗性和性能优势；有一个非匿名的，来自大学的领导者
• 解决了一些 I2P 尚未解决的规模问题
• 有可观的资金
• 有更多的开发者，其中有些是全职的
• 由于具有基于 TLS 的传输和网桥，对国家级封锁有更强的抵抗 （I2P 有“完全限制路由”的提案，但还没有实现）
• 足够大所以它已经适应了封锁和拒绝服务攻击
• 为出口流量设计和优化，有大量的出口节点
• 更好的文档，拥有正式文件和规范， 更美观的网页，多许多的翻译
• 内存使用更高效
• Tor client nodes have very low bandwidth overhead
• Centralized control reduces the complexity at each node and can efficiently address Sybil attacks
• A core of high capacity nodes provides higher throughput and lower latency
• C，而不是Java（嗯哼）

I2P 相对 Tor 的优势

• 专为隐藏服务设计和优化，在这方面比 Tor 快许多
• 完全分布式和自组织
• 通过不断分析和比较性能，而不是根据目录声称的流量来选择节点
• 种子节点（“目录服务器”）是持续变化并且不被信任的， 而不是硬编码写入
• 足够小以至于它还没有被大量（或者根本没有）封锁或拒绝服务
• P2P 友好
• 包交换而不是电路交换
  • implicit transparent load balancing of messages across multiple peers, rather than a single path
  • resilience vs. failures by running multiple tunnels in parallel, plus rotating tunnels
  • 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)
• Unidirectional tunnels instead of bidirectional circuits, doubling the number of nodes a peer has to compromise to get the same information. Counter-arguments and further discussion here.
• 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)
• 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.
• I2P APIs are designed specifically for anonymity and security, while SOCKS is designed for functionality.
• 基本上所有节点都参与为其他人的路由
• 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.
• Integrated automatic update mechanism
• 使用TCP和UDP传输
• Java，而不是C（嗯哼）

Other potential benefits of I2P but not yet implemented

...and may never be implemented, so don't count on them!

• Defense vs. message count analysis by garlic wrapping multiple messages
• Defense vs. long term intersection by adding delays at various hops (where the delays are not discernible by other hops)
• 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)