Comparisons with Tor and Freenet ***

[luciewho]

Comparison Tor Freenet.pdf

There are two pages in the PDF. First page is the original copy from https://geti2p.net/en/comparison/tor and https://geti2p.net/en/comparison/freenet

The second page is the "Similar Systems" section pulled from Tech Intro https://geti2p.net/en/docs/how/tech-intro

The two pages need to be consolidated and simplified or one of the pages removed.

[Shoalsteed]

Freenet ( Combined and condensed )

Freenet played a large part in the initial stages of I2P's design. It showed what could be possible for a pseudonymous community that was completely contained within the network. It also demonstrated that the dangers inherent in outproxies could be avoided.

The first seed of I2P began as a replacement communication layer for Freenet, attempting to factor out the complexities of a scalable, anonymous and secure point to point communication from the complexities of a censorship resistant distributed data store. Over time however, some of the anonymity and scalability issues inherent in Freenet's algorithms made it clear that I2P's focus should stay strictly on providing a generic anonymous communication layer, rather than as a component of Freenet.

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.

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 attempts to develop a distributed data store to run on top of I2P, (most recently a port of Tahoe-LAFS) but nothing is yet ready for general use.

However, even ignoring any implementations issues, there are some 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.

[Shoalsteed]

Tor

At first glance, Tor and I2P have many functional and anonymity related similarities. While I2P's development began before we were aware of the early stage efforts on Tor, many of the lessons of the original onion routing and ZKS efforts were integrated into I2P's design. Rather than building an essentially trusted, centralized system with directory servers, I2P has a self organizing network database with each peer taking on the responsibility of profiling other routers to determine how best to use available resources. Another key difference is that while both I2P and Tor use layered and ordered paths (tunnels and circuits/streams), I2P is a packet switched network, while Tor is a circuit switched one, allowing I2P to transparently route around congestion or other network failures, operate redundant pathways, and load balance the data across available resources.

While Tor offers the useful outproxy functionality by offering integrated outproxy discovery and selection, I2P leaves such application layer decisions up to applications running on top of I2P - in fact, I2P has even externalized the TCP-like streaming library itself to the application layer, allowing developers to experiment with different strategies, exploiting their domain specific knowledge to offer better performance.

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

Benefits of Tor over I2P Much bigger user base; much more visibility in the academic and hacker communities; benefits from formal studies of anonymity, resistance, and performance. Has already solved some scaling issues I2P has yet to address 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) ?????? Big enough that it has had to adapt to blocking and DOS attempts Designed and optimized for exit traffic, with a large number of exit nodes Better documentation, has formal papers and specifications, many more translations More efficient with memory usage 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

[Shoalsteed]

Benefits of I2P over Tor Designed and optimized for hidden services, which are much faster than in Tor Fully distributed and self organizing Peers are selected by continuously profiling and ranking performance, rather than trusting claimed capacity Floodfill peers ("directory servers") are varying and untrusted, rather than hardcoded Small enough that it hasn't been blocked or DOSed much, or at all Peer-to-peer friendly Packet switched instead of circuit switched 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. Essentially all peers participate in routing for others 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 Both TCP and UDP transports