Having examined the existing anonymous networks and discussing the options in a group meeting, we narrowed down our choices to either the TOR network or the I2P network. We then proceeded to examine the various strengths and weaknesses of the two networks, before finally settling upon I2P. Below are the technical factors that lead us to our choice:

• I2P is completely decentralized, unlike Tor where a ‘directory’ of the network is maintained. Rather than building an essentially trusted, centralised 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 exploit available resources.
• While Tor was designed with the intention to enable anonymous Internet browsing, I2P’s focus is to provide an anonymous network, isolated inside the Internet, offering various protocols and applications within. Furthermore, I2P is designed and optimised for “hidden services” (i.e. websites and other services hosted within I2P), and they are much faster than the corresponding ones on the Tor network, as the I2P network is fully distributed and self-organizing.
• Content hosted on networks such as Freenet are mostly static, whereas websites hosted within I2P can be fully dynamic
• I2P is fundamentally a packet switched network whereas Tor is fundamentally a circuit switched network. This allows I2P to transparently route around congestion and other network failures, operate redundant pathways and load balance the data across available resources.
• Although Tor is more popular and has significantly more funding than the I2P network, in recent times the network has become incredibly saturated and is more vulnerable. In contrast, the smaller size of I2P has allowed it thus far to float beneath the radar of government censors and malicious users.
• The unidirectional tunneling system used by I2P doubles the amount of nodes that a peer needs to compromise to get the same information that could be obtained from Tor’s bidirectional tunneling system. In addition to this, 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.

Architecture of I2P (the following section was taken from the technical documentation of I2P, located here):

How it works:
I2P uses bundled encryption over a multi-proxy like Tor. The packets are bounced all over the globe using I2P. However, the packets are encrypted with EIGamal and AES encryption. Using bundled encryption like this allows a packet to only decrypt the next hop as it passes through various nodes on its path. Once inside the network, IP addresses are not even used. Your node is assigned an address of garbled text to use an identifier.

I2P uses virtual, unidirectional tunnels that pass through a series of routers, and are typically 2 to 3 hops. Each round trip message and reply will require 4 tunnels. One for each the sender and receivers inbound/outbound traffic. Tunnels are created using what is known as ‘garlic routing’. A tunnel build message is sent via garlic routing to an I2P router requesting that it participate in a tunnel.

I2P makes a strict separation between the software participating in the network (a ‘router’) and the anonymous endpoints (‘destinations’) associated with individual applications. The fact that somebody is running I2P isn’t usually a secret. What is hidden is the information on what the user is doing as well as what router a particular destination is connected to. End users will typically have several local destinations on their router.

Tunnels:
A tunnel is a directional path through an explicitly selected list of routers. Layered encryption is used, so each of the routers can only decrypt a single layer. The decrypted information contains the IP of the next router, along with the encrypted information to be forwarded. Each tunnel has a starting point (the 1st router (gateway)) and an endpoint. Messages can only be sent one way. To send messages back, another tunnel is required.
Two types of tunnels exist:

• “Outbound” tunnels send messages away from the creator.
• “Inbound” tunnels bring messages to the tunnel creator.

While the tunnels themselves have layered encryption to prevent unauthorized disclosure to peers inside the network (as the transport layer itself does to prevent unauthorized disclosure to peers in the network), it is necessary to add an additional end to end layer of encryption to hide messages from the outbound tunnel endpoint endpoint and the inbound tunnel gateway. This achieved by a process known as ‘garlic routing’.

Garlic Routing:
I2P uses an extension of the well-known onion routing approach, in which a message is routed from its originator to the final endpoint through several intermediate nodes using layered encryption. The originator adds to the message to be sent an encryption layer for every node in the path, each intermediate node peels off one of these layers, exposing routing instructions along with still-encrypted payload data, and finally the last node removes the final layer of encryption, exposing the original message to the endpoint. This process is called garlic routing, and allows to the originator include several messages in a single onion. I2P currently uses this approach to include the return destination for a given message as well as status messages.
The ‘instructions’ attached to each clove inside the encryption layer includes the ability to request that clove be forwarded locally, to a remote router, or to a remote tunnel on a remote router. There are fields in those instructions allowing a peer to request that a delivery be delayed until a certain time or condition has been met, though they won’t be honoured until the non-trivial delays are deployed.

Network Database (NetDB):
The NetDB uses a pair of algorithms which are used to share network metadata. The two types of metadata carried are “routerinfo” and “leasesets” – the routerinfo gives routers the data necessary for contacting a particular router (their public keys, transport address etc.) while the leaseset give routers the information necessary for contacting a particular destination. The full info contained in the leaseset is:

• Inbound gateway for a tunnel that allows reaching a specific destination.
• Time when a tunnel expires.
• Pair of public keys to be able to encrypt the messages (to send through the tunnel).

Routers themselves send their router information to the netDB directly, while leasesets are sent through outbound tunnels (leasesets need to be sent anonymously, to avoid correlating a router with his leaseset).

The following sources were used for this post:

1. I2P vs. Tor & Freenet
2. Tor vs. I2P: The Great Onion Debate
3. Why Tor has failed, but I2P will not.