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.

TorとI2Pの用語の比較

TorとI2Pは多くの点で似ていますが、多くの用語は異なっています。

Benefits of Tor over I2P

• 遥かに大きな利用者の基盤。遥かに多い学術界とハッカー界内での知名度。匿名性、抵抗、及び性能の正式な精査からの便益。非匿名者に目立ち、大学基盤の先導者がいる。
• I2Pではまだ中途である、需要増大による問題が既に解決されている
• かなりの資金を持つ
• 資金提供を受けている数人を含め、より多い開発者がいる
• TLSトランスポート層とブリッジのお陰で、国家級の遮断へのより強い耐性 （I2Pは"full restricted routes"のための提案があるが、まだ実装されていない）
• 遮断とDOSに順応するための十分に大きな試みがある
• 外へのトラフィック用に設計と最適化がされ、多数の出口ノードがある
• 公式文書と仕様集のように、より良い資料を持ち、より良いウェブサイトや、遥かに多い翻訳がある
• より効率的なメモリ使用量
• Torのクライアントノードでは、帯域幅の余剰が非常に小さい
• 一元化された制御が各ノードで複雑さを減らし、Sybil攻撃への対処が効率的に可能
• 中心となる高性能なノードが高効率と低遅延を提供する
• Java言語ではなくC言語（笑）

Benefits of I2P over Tor

• 秘匿サービス用に設計と最適化がされ、Tor内よりとても高速
• 完全に分散化され、自ら整理する
• ピアが主張する許容量を信頼するのではなく、 間断なくプロファイルと性能の順位付けを行うことによってピアが選択される
• Floodfill peers ("directory servers") are varying and untrusted, rather than hardcoded
• 十分に小さいので、遮断されたりDOSを受けたりすることはあまりない。
• ピアツーピアに調和的
• 回路が交換されるのではなく、パケットが交換される
  • 単一の経路ではなく、複数のピアと交差するメッセージの、利用者の意に介さない潜んだ負荷分散
  • 複数のトンネルが並行して稼働し、加えてトンネルを交換させることで、障害に強い。
  • 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.
• トンネルは、単なる端末から端末までのメッセージの受け渡し以外（例えば、netDb、トンネル管理、トンネル試験など）にも使われ、 攻撃者がトンネルに参加している場合であっても、クライアントの活動内容の探り当てに強く、保護がある
• I2Pでのトンネルは、Torでの大抵は長命な回路とは異なり短命であり、攻撃者が能動的な攻撃を仕掛ける際に用いる標本の数を減らしている。
• SOCKSが機能性のために設計されているのに対して、 I2P APIは、明確に匿名性と安全性のために設計されている。
• 基本的に、全ピアが他者のために経路中に参加する
• 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.
• 統合された自動更新の仕組み
• TCPとUDPの両トランスポート
• C言語ではなくJava言語（笑）

I2Pのその他の潜在的な利点だが、まだ実装されていない

…全く実装されないかもしれないので、期待しない方が良いだろう！

• 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)