Tor vs i2p: comparison

[Tomcat]

Introduction
Tor and Onion Routing are anonymous proxy networks that allow users to tunnel data through their network with low latency. The two main differences between Tor and I2P are based on the difference in threat models and the design of the exit proxy nodes (although Tor supports hidden services, just like I2P). In addition, Tor implements a centralized point for managing network visibility, as well as collecting statistics, in contrast to the distributed I2P network model, network base and peer selection.
The exit node function in I2P / Tor has several obvious problems - once data leaves the network, global observers can easily monitor this traffic. In addition, the exit nodes have access to unencrypted data in both directions, and are also easily detected and susceptible to various kinds of attacks in the real world. This is all in addition to the usual security issues we know.
However, many people do not need to worry about this because they are beyond the threats of the model. They are also outside the (formal) I2P boundary (if people need to make an exit node, they can do it). In fact, a number of I2P users use Tor as their exit node.

Comparison of Tor and I2P terminology
While Tor and I2P are similar in many ways, their terminology is significantly different.
Tor / I2P
Cell / Message
Client / Router or Client
Chain / Tunnel
Reference / NetDb
Directory Server / Floodfill Router
Entrance Guardians / Swift Feasts
Input Nodes / Input Proxy
Output Node / Output Proxy
Hidden Service / Eepsite or Appointment
Hidden Service Descriptor / LeaseSet
Introduction / Entrance Gateway
Host / Router
Onion Proxy / I2PTunnel client (more or less)
Relay / Router
Meeting point / something like Entry gateway + Exit point
Router descriptor / RouterInfo
Server / Router

Tor advantages over I2P

• Significantly large user base; More attention from science and the hacker community; the benefits of formal research on anonymity, resistance, and productivity; known not anonymous, visible, university-related lide
• Already resolved a number of scaling issues that I2P just can't handle
• Has significant funding
• More developers, including a number of paid ones
• More resistant to blocking at the state level, thanks to transport over TLS and bridging (I2P has proposals for "completely closed paths", but they have not yet been implemented
• Large enough network to adapt to blocking and DOS attempts
• Designed and optimized for traffic egress, with a large number of egress nodes
• Better documentation, research and specs, better website, much more translated data
• More efficient in memory usage
• Tor clients operate with very little protocol overhead
• Centralized control reduces the complexity of each node and can effectively deal with Sybil attacks
• A set of high performance nodes provides high performance and lower latency
• Implementation in C, not Java

Advantages of I2P over Tor

• Designed and optimized for hidden services, much faster than Tor
• Fully distributed and self-organizing network
• Peers are selected based on continuous profiling and performance measurements rather than peer-announced throughput
• The Floodfill peers ("reference servers") are constantly changing and not trusted, unlike the explicit ones in Tor
• Small enough to be heavily blocked by either DOS or.
• Provides peer-to-peer services
• Switches packets rather than connections
• Explicit transparent balancing of messages across many peers, as opposed to using a single path
• Reliability and resiliency by maintaining multiple parallel tunnels and ensuring tunnel rotation, the connections of each user are scaled as O (1) instead of O (N) (for example, Alice holds 2 incoming tunnels, which can be used by any peer with which Alice communicates, and does not hold chain for every feast)
• One-way tunnels, instead of two-way chains, doubling the number of nodes a peer must compromise to get the same information
• Protection against detection of client activity, even if the attacker participates in the tunnel, since tunnels are used not only to transfer messages, but also to operate NetDb, manage tunnels, check the health of tunnels)
• I2P implements short-lived tunnels, which reduces the number of examples that an attacker can use to attack, in contrast to chains in Tor, which tend to live long.
• I2P APIs are designed for anonymity and security, while SOCKS is made for functionality.
• With rare exceptions, all peers are involved in routing traffic to others.
• The cost of running in full mode is quite low, whereas in Tor, if the client itself does not require a lot of bandwidth, they still do not fully utilize the network.
• Built-in automatic update mechanism
• Both TCP and UDP transport are used
• Java implementation, not C

Other potential but not yet realized benefits of I2P
... and possibly never realizable, so don't count on them

• Protection against quantitative analysis of messages by wrapping multiple messages into one
• Protection from statistical analysis by adding delays on different hops (where delays are independent of other hosts)
• Different strategies for spoofing at the tunnel level (for example, creating a tunnel that will process 500 messages per minute, where the endpoint sends random data if no useful traffic is transmitted, etc.)