I2P Tunnels: Garlic Encryption and Unidirectional Data Transmission

The anonymity of I2P network participants is achieved through the use of tunnels. A key feature of I2P is that only the creator of a tunnel knows its length, start, and end points. Each node in the network has its own inbound and outbound tunnels and, by default, also acts as a transit node in other participants’ tunnel chains. I2P tunnels are unidirectional—traffic only flows in one direction through each tunnel. In the anonymous network, a user does not have direct access to the recipient on the other side; they only have information about the entry node in their inbound tunnel. To contact another participant’s inbound tunnel, the connection is made through an anonymizing chain on the sender’s side—via their outbound tunnel. After establishing contact, the recipient is informed about the inbound tunnel of the sender for reply purposes. For details on how nodes find each other’s inbound tunnels for the first contact, see the article on floodfills.

Chains of multiple nodes are one of the most important logical components of I2P. In this article, we’ll explain how these chains are built and demonstrate why the level of anonymity in I2P can be trusted.

Transports

The most common low-level network protocols today are TCP and UDP. They handle the delivery of information between subscribers but do not provide any privacy—anyone can intercept the data in transit. Therefore, higher-level application protocols require encryption.

I2P uses the transport protocols NTCP2 (an analog of TCP) and SSU (an analog of UDP). These protocols are essentially cryptographic wrappers around their traditional counterparts. Data in the “invisible internet” is transmitted via these protocols, hiding all information from your home ISP.

NTCP2 and SSU not only encrypt data but also add a random number of extra bytes. This “noise” thwarts traffic analysis systems, as packet sizes become random and meaningless. After decryption at the destination, the extra bytes are simply discarded.

NTCP2 and SSU are tools for secure peer-to-peer connections—direct links between network routers. Since anonymity in I2P is achieved through tunnels made up of several intermediate nodes, we won’t focus on direct node-to-node communication here, but rather on anonymizing tunnels. For more on the NTCP2 transport protocol, see the detailed article in Russian.

What Is a Tunnel?

I2P routers (all network nodes) communicate using the I2NP protocol. The full list of I2NP message types can be found in the source code or in the official documentation.

I2NP provides a comprehensive set of message types needed for I2P routers to communicate. Pay attention to the types containing the word Tunnel—these are relevant here. All user data is transmitted inside tunnels as encrypted blocks from router to router, so the original source is lost, and the true recipient remains unknown, as it’s unclear at which transit router the tunnel ends.

Tunnel logic has two main requirements: the creator’s anonymity from tunnel participants, and transport compatibility among transit nodes. For a brief overview of tunnel construction, see the main I2P article. Here, we’ll dive deeper into this complex mechanism and reaffirm that I2P’s anonymity level is truly unique.

I2P Architecture Compared to a Regular Network

To make this less like a dry specification, let’s simplify the I2P network architecture by comparing it to a regular network.

• Your device connects to the internet via a router (wired, Wi-Fi, or cellular). Before establishing a logical IP connection, the device exchanges low-level service information (e.g., Ethernet frames).
• Once the IP connection is established, you can access computers worldwide. When you open a website, your traffic passes through many transit nodes (ISPs), but you only have a direct connection to your initial router. All intermediate nodes operate at the IP level, forwarding packets from point A to point B.
• Each device and router establishes low-level connections with physical neighbors, forming IP networks with familiar IPv4 or IPv6 routing. The highest TCP/IP level is the “application” layer—user traffic, like a browser’s HTTPS request. Lower levels know nothing about your site or browser; they just deliver binary data to its destination.

I2P operates on top of TCP/IP but adds its own structure, partially mirroring a regular network but with a strong focus on privacy and anonymity. The I2P router is a software client on your device that manages all internal network logic. I2NP messages are the basic communication tool between I2P routers. Tunnels are analogous to IP connections, enabling direct interaction with other routers and, through them, with nodes you can’t contact directly. The highest level—”garlic message”—is user data delivered via tunnels, meaningful only to the final recipient who can decrypt it.

Messages from the hidden network travel through the regular internet, but their content is only meaningful at a higher level, which requires an I2P router to access. This is called an overlay network. Technically, the term “deep internet” for I2P and other hidden networks should be the opposite—something like “high-level internet.”

Garlic Messages and Tunnel Formation

Each I2P router publishes information about itself on floodfills—the network’s directory nodes. The full router address is called “Router Info” (RI). In addition to reachability info (IP addresses and introducer addresses) and some service data, RI contains the router’s public encryption key.

The local I2P router database consists entirely of other participants’ RI files. When a router needs to build a tunnel, it first selects its future participants from the local netDb, considering declared bandwidth, transport compatibility, and profile data (if available). Profiling means the router keeps a local history of interactions with specific nodes and rates their stability—unstable routers won’t be used for tunnel construction.

Once candidates are chosen, a garlic message is created. If the tunnel is four hops or fewer, the garlic always contains four cloves (messages). Otherwise, it contains eight messages (the maximum tunnel length). By default, tunnels are three transit nodes long.

The garlic message principle is that each tunnel participant receives the full set of messages (the garlic) but can only read the clove intended for them. The entire garlic message is then forwarded according to the instructions in the clove. Cloves are identified by the first 16 bytes, which are the start of the hash of their encryption key. After reading the garlic message, the participant replaces the clove’s content with their response, encrypted with a symmetric key for secrecy.

An interesting nuance: a node can only see its own clove in the garlic, preventing it from guessing other tunnel participants by their key hashes. This is achieved by additional symmetric encryption of the entire garlic. For the curious, see the source code.

Currently, there are three types of garlic messages:

• Old: Used when all transit routers use El Gamal encryption. Each message is 528 bytes and contains AES keys: a one-time key for response encryption, an initialization vector (IV), an IV encryption key, and a main key for tunnel (onion) encryption.
• Transitional: Used when transit routers include both El Gamal and new ECIES nodes. Each message is 528 bytes, but ECIES nodes use different response encryption: the symmetric key is not sent directly but computed via the Noise protocol (Noise_N).
• New (“short garlic messages”): Used when all transit routers use ECIES encryption and are version 2.39.0+ (i2pd) or 1.5.0+ (Java router). Each message is 218 bytes. Cloves don’t contain the above keys, as they’re all computed. AES is used only as the main tunnel key; otherwise, AEAD/Chacha20/Poly1305 and ChaCha20 algorithms are used. See the specification for details.

The new garlic message type is unique for its size—a standard four-clove garlic fits in one kilobyte. As of this article, all I2P tunnel messages are split into one-kilobyte fragments, a standard size to combat traffic analysis.

A minimum-size garlic with 528-byte cloves requires sending three tunnel messages. Despite traffic obfuscation, in theory, one could spot a pattern: three consecutive kilobyte messages may indicate a standard garlic. If such traffic is observed, the user is likely building a tunnel or acting as a transit node. In practice, this is far-fetched, as tunnels last only ten minutes, and active nodes participate in over 2,000 transit tunnels at once—imagine how many garlics pass through such a router every minute!

With short messages, the entire garlic fits in a single tunnel message, blending completely with other traffic. This eliminates the last hope for spies to analyze traffic for three consecutive kilobyte messages. But it’s not just about paranoia! One tunnel message instead of three also speeds up tunnel building: fewer packets mean less chance of loss and faster transmission.

Inbound and outbound tunnels are built similarly:

• Inbound tunnel: To remain anonymous, the creator sends the garlic to the first participant via their outbound tunnel. The garlic is then passed from node to node and returns to the creator. For the last node, the creator is indistinguishable from any other transit node.
• Outbound tunnel: The creator sends the garlic directly to the next router in the chain, which can’t know if the sender is the garlic’s owner or just another transit node. The last transit node’s clove contains info for sending the garlic back to the creator. After traversing the chain, the garlic returns to the creator via one of their inbound tunnels.

When I2P starts, the router has no real tunnels, only two zero-length tunnels. The first real tunnels are built directly (not via anonymizing chains) through the zero-length tunnel. Since this is rare and indistinguishable from normal operation, it’s not considered a weakness in I2P’s architecture.

Tunnels in Practical Network Context

Garlic cloves contain not only encryption keys but also tunnel numbers (each 4 bytes). One number is for the tunnel the router will receive messages on, and the other is for the next transit node, whose address is included, to which the current router will forward data.

Garlic messages only contain short router addresses for the next hop. The router address is a SHA256 hash of its full Router Info. If the required router isn’t in the local database, the transit node must query a floodfill to get its full address (RI). When building the garlic, the tunnel creator ensures transport compatibility between neighbors, reducing the chance of failed tunnel construction (e.g., not asking an IPv4-only router to contact an IPv6-only node).

A tunnel is considered failed if a response takes too long or if the garlic returns with a refusal from any router (possibly due to transit tunnel limits, etc.).

Once created, a tunnel’s lifespan is limited to ten minutes. After that, all transit nodes stop accepting packets for the old tunnel, and the creator must have a new tunnel ready—it’s built shortly before the old one “expires.” After updating inbound tunnels, if it’s a server endpoint waiting for connections, its lease set (contact info on floodfills, including inbound tunnel info) is also updated.

Garlic encryption is only used in I2P when building tunnels. During normal operation, only onion encryption is used in the tunnel (plus end-to-end encryption between users).

Onion encryption means multi-layer symmetric key encryption. In symmetric encryption, the same key is used for both encryption and decryption, unlike asymmetric algorithms, where encryption uses a public key and decryption uses a private key. Asymmetric encryption is used for end-to-end encryption.

All tunnels are unidirectional, and transit nodes know nothing: whether the tunnel is inbound or outbound, how many participants there are, etc. Their job is to encrypt passing data with the received (or mathematically derived) symmetric key and forward the packet to the next node.

Only the end nodes have special roles: for an outbound tunnel, the last node is the Endpoint; for an inbound tunnel, the first node is the Gateway. Unlike regular “middle” nodes, these two know their place in the chain via special flags in the garlic. The Endpoint’s job is to collect kilobyte tunnel messages into larger packets (up to 64 KB) and forward them as instructed (into an inbound tunnel, directly to another router, or for local processing). The Gateway does the opposite: splits received messages into standard one-kilobyte fragments and sends them down the inbound tunnel.

When sending a packet, the router sequentially decrypts it with all transit node keys. This is so that after each transit node encrypts the data, it ends up in its original form. This is a feature of symmetric algorithms like AES and ChaCha20. It may sound complicated, but encryption and decryption are mirror operations: to decrypt the original data, you must perform the reverse operation (i.e., encrypt).

At the last router of the outbound tunnel (the Endpoint), the final layer of onion encryption is removed, and the data is sent into the inbound tunnel of the other side. Even though all onion encryption is removed at this point, user data is still protected by end-to-end encryption.

In the inbound tunnel, things are simpler: each transit node adds its own encryption layer, then forwards the packet. The final recipient, after removing all onion encryption, decrypts the data with their asymmetric key and verifies the signature. The decrypted data is then passed up to the external (application) layer in its original form.

In summary, the user data transmission scheme looks like this:

• Outbound tunnel:
  1. The I2P router receives data from a local application and packs it into I2NP Data (gzip + headers).
  2. End-to-end encryption is applied using the recipient’s key (from the lease set), resulting in I2NP Garlic.
  3. The data is prepared for a specific tunnel, forming an I2NP Tunnel message.
  4. Traffic is wrapped in the transport protocol’s cryptography.
  5. The data is sent over the physical network to the first node of the outbound tunnel.
• Inbound tunnel:
  1. Packets destined for the I2P router arrive over the network.
  2. Transport protocols are processed, and I2NP messages are decrypted.
  3. The message is an I2NP Tunnel (tunnel message).
  4. By the tunnel ID, the router knows the message came from its tunnel. Onion encryption is removed.
  5. The I2NP Garlic message is the sender’s original message, encrypted with the recipient’s asymmetric key. The router, as the address holder, decrypts it with its private key (in reality, one-time keys and more are used, but let’s keep it simple!).
  6. The result is I2NP Data—user data (gzip + headers), which is unpacked and delivered to the external application.

Note: The focus here is on user data from the tunnel, but there are many service messages handled differently.

It’s important to note that I2NP Garlic is just a type indicating a message with single-layer end-to-end encryption, not the garlic message used for tunnel construction. Perhaps garlic encryption was once planned for this, but practical implementation took a different path.

This is a simplified explanation of how I2P tunnels work, but despite all efforts to make it easier, the material is still quite complex. Nevertheless, the most important thing is to have at least some understanding of the technology you choose to rely on for important tasks.

Our other channels

Our friends and partners