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.

Vergleich der Tor- und I2P-Terminologie

Obwohl Tor und I2P in vielerlei Hinsicht ähnlich sind, ist ihre Terminologie weitgehend anders.

Vorteile von Tor gegenüber I2P

• Viel größere Nutzerbasis; kommt im akademischen Bereich und bei Hacker-Communities viel häufiger vor; profitiert von wissenschaftlichen Studien über Anonymität, Resistenz und Performanz; hat einen nicht-anonymen, bekannten Projektleiter an einer Universität
• Hat bereits einige Skalierungsprobleme gelöst, die I2P noch angehen muss
• Hat bedeutende finanzielle Unterstützung
• Hat mehr Entwickler, davon mehrere mit finanzieller Unterstützung
• Resistenter gegenüber staatlichem Sperren wegen der TLS Transportschicht und Bridges (bei I2P gibt es Vorschläge für "full restricted routes", aber diese sind noch nicht umgesetzt)
• Groß genug, dass es sich auf Blocking und DOS-Attacken einstellen musste
• Ausgerichtet und optimiert auf Exit-Traffic mit einer großen Anzahl von Exit-Knoten
• Bessere Dokumentation, hat wissenschaftliche Arbeiten und Spezifikationen, bessere Website, viel mehr Übersetzungen
• Effizienter bei der Nutzung des Arbeitsspeichers
• Client-Knoten bei Tor haben sehr geringen Bandbreiten-Overhead
• Centralized control reduces the complexity at each node and can efficiently address Sybil attacks
• Ein Kern von Knoten mit hoher Kapazität sorgt für höheren Durchsatz und niedrigere Latenz
• C, nicht Java (ewww)

Vorteile von I2P gegenüber Tor

• Designed and optimized for hidden services, which are much faster than in Tor
• Vollkommen verteilt und selbst-organisierend
• Peers werden mittels fortlaufender Profilbildung und Performanzeinstufung ausgewählt, anstatt der von ihnen selbst angegebenen Kapazität zu vertrauen
• Floodfill peers ("directory servers") are varying and untrusted, rather than hardcoded
• Klein genug, dass es bisher kaum oder gar keine Blockierungen bzw. DOS-Attacken gab
• Für Peer-to-Peer geeignet
• Paket-basiert anstatt Verbindungs-basiert
  • 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)
• Unidirektionale Tunnel statt bidirektionaler Schaltungen, was die Zahl der zu kompromittierenden Stellen verdoppelt um an dieselbe Information zu gelangen. Gegenargumente und weitere Erörterung hier.
• 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.
• Im Prinzip sind alle Peers daran beteiligt, für andere zu routen
• 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.
• Integrierter automatischer Aktualisierungsmechanismus
• Sowohl TCP- als auch UDP-Transport
• Java, nicht C (ewww)

Weitere potentielle Vorteile von I2P, aber noch nicht implementiert

...und die vielleicht niemals implementiert werden, also nicht darauf verlassen!

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