Garlic Routing: How I2P Bundles Messages to Frustrate Surveillance

Tor uses onion routing, wrapping messages in encryption layers that each relay peels away. I2P uses garlic routing, a variant that bundles multiple messages together before applying those encryption layers. Michael J. Freedman coined the term, calling each bundled message a "bulb" in his academic work, though I2P uses the term "clove" to match the garlic metaphor.

The garlic approach addresses a fundamental problem with anonymous networks: unidirectional tunnels require multiple round trips for reliable communication. When your outbound tunnel can only send messages away from you and your inbound tunnel can only receive messages coming toward you, a single request-response cycle needs four separate tunnels to complete.

The Four-Tunnel Reality

Consider sending a message to an I2P service. Your message travels through your outbound tunnel (3 hops) to the service's inbound tunnel (3 hops). The service's response travels through their outbound tunnel (3 hops) to your inbound tunnel (3 hops). That rounds to 12 router hops for one exchange, compared to the 6 hops a bidirectional circuit would require.

I2P chose unidirectional tunnels deliberately. When tunnels carry traffic in only one direction, a compromised router sees encrypted data flowing one way. Bidirectional tunnels, like Tor uses, expose both directions to the same hops, making traffic correlation attacks easier. The four-tunnel architecture doubles the path length but eliminates turning points where an attacker could observe both request and response patterns.

Cloves and Message Bundling

A garlic message wraps one or more cloves, each with its own delivery instructions. The primary clove carries your actual data: the webpage request, the chat message, the file chunk. Additional cloves piggyback on the same encrypted bundle for efficiency.

Three types of cloves commonly travel together. The Delivery Status Message routes back to the sender as an acknowledgment, confirming the primary clove reached its destination. When this acknowledgment times out, the sender adjusts its routing strategy. The Database Store Message carries the sender's current LeaseSet, the cryptographic structure listing their active tunnel endpoints. Bundling the LeaseSet means the recipient can reach the sender without querying the network database.

The router bundles cloves when specific conditions trigger: LeaseSet changes, session tag deliveries, or approximately every minute by default. This periodic bundling ensures both parties maintain current connection information without dedicated synchronization traffic.

ElGamal/AES+SessionTag Encryption

I2P originally used a hybrid encryption scheme called ElGamal/AES+SessionTag for end-to-end garlic encryption. The system combines 2048-bit ElGamal asymmetric encryption for key establishment with AES-256-CBC symmetric encryption for message payloads.

The first message between two parties uses full ElGamal encryption. The sender encrypts session key material asymmetrically, producing a 514-byte encrypted block containing a 32-byte session key, a 32-byte Pre-IV, and 158 bytes of random padding. The AES-encrypted payload follows this block, containing the actual message plus a batch of session tags for future use.

Session tags are 32-byte random values that function as one-time tokens. Each tag can be used exactly once to encrypt a subsequent message. When the sender wants to transmit again, they pick an unused session tag, use it as the Pre-IV for AES encryption, and prepend the tag to the ciphertext. The recipient checks incoming 32-byte headers against their stored session tags; a match indicates an existing session message rather than a new ElGamal-encrypted connection.

Session Tag Lifecycle

Session tags expire if unused and vanish after single use. The sender pre-delivers enough tags to cover expected message volume, bundled inside the AES-encrypted portion of earlier messages. The tag count field allows up to 200 tags per message, though practical implementations deliver fewer based on traffic patterns.

Single-use enforcement serves a critical privacy function. If an adversary captures encrypted traffic, repeated session tags would reveal which messages belong to the same conversation. By consuming each tag on first use, sequential messages appear unrelated to anyone watching the encrypted stream.

The Pre-IV derivation adds another layer of cryptographic separation. The actual AES initialization vector comes from the first 16 bytes of SHA-256(session_tag), ensuring each message uses a unique IV without transmitting additional data. This prevents the IV reuse attacks that plague naive symmetric encryption implementations.

Unidirectional Session Management

Sessions flow in one direction only. When Alice establishes a session with Bob, she delivers session tags that only she uses in subsequent messages to Bob. Bob establishes a separate reverse session by delivering his own tags to Alice. Each party maintains independent Session Key Managers tracking their outstanding tags and corresponding session keys.

This separation prevents correlation between destinations. If Alice runs multiple services on the same router, each service maintains its own Session Key Manager. An adversary who compromises one session cannot link it to others through shared cryptographic state.

Delivery Instructions and Routing

Each clove carries Delivery Instructions specifying its routing target. The target can be a Destination (identified by its cryptographic identity), a Router (identified by its router hash), or a specific Tunnel (identified by gateway router and tunnel ID).

Since release 0.9.12, Delivery Status Messages are encrypted inside additional garlic messages, hiding their acknowledgment nature from intermediate routers. Earlier implementations sent acknowledgments in plaintext cloves, leaking information about which messages succeeded.

The Delivery Instructions format also supports local delivery for messages that terminate at the current router rather than continuing to another hop. This enables efficient handling of router-to-router traffic without unnecessary tunnel traversal.

Differences from Tor's Onion Routing

Tor builds bidirectional circuits and wraps individual messages in onion encryption. I2P bundles messages and uses unidirectional tunnels with garlic encryption. The practical differences extend beyond terminology.

Tor's circuit construction requires interactive handshakes with each relay, establishing session keys through Diffie-Hellman exchanges. I2P's tunnel construction uses non-interactive build messages where keys are pre-computed using the relay's published public key. The garlic layer adds end-to-end encryption on top of the tunnel encryption, creating separation between who can read tunnel headers versus message contents.

Message bundling gives I2P an efficiency advantage for its acknowledgment-based reliability. Tor circuits carry individual cells; the circuit itself provides ordering guarantees. I2P tunnels carry unordered messages, so the garlic layer handles acknowledgment and retransmission logic. Bundling the acknowledgment with outgoing data minimizes the overhead of this reliability layer.

The ECIES-X25519-AEAD-Ratchet Migration

ElGamal/AES+SessionTag served I2P for years, but the protocol shows its age. ECIES-X25519-AEAD-Ratchet is replacing the legacy encryption, using modern primitives: X25519 for key exchange and ChaCha20/Poly1305 for symmetric encryption.

The new protocol provides forward secrecy through ratcheting key derivation. Each message derives new encryption keys from the previous state, so compromising a future key reveals nothing about past traffic. ElGamal/AES+SessionTag reused session keys until tag exhaustion, exposing all messages if the session key leaked.

The ratchet also reduces message overhead. ChaCha20/Poly1305 produces shorter ciphertexts than AES-CBC with explicit IVs, and X25519 key material is smaller than 2048-bit ElGamal parameters. This efficiency matters for a network where every byte crosses multiple encrypted hops.

Garlic Message Structure

The AES block structure reveals the layered design. After the session key or session tag header, the encrypted content contains: a 2-byte tag count (0-200), the session tags themselves (32 bytes each), a 4-byte payload size, a 32-byte SHA-256 hash of the payload, a flag byte for optional session key replacement, the actual payload data, and random padding to 16-byte alignment.

The payload hash enables integrity verification without additional MAC overhead. If the decrypted hash matches the computed hash, the message arrived intact. Any bit flip in transit causes hash mismatch and message rejection.

The padding requirement enforces a minimum 48-byte overhead, preventing attackers from precisely inferring message sizes. Variable padding up to 16-byte alignment adds further noise to traffic analysis attempts.

Why Unidirectional Tunnels Matter

The four-tunnel requirement seems inefficient until you consider the alternative. Bidirectional tunnels expose every hop to traffic in both directions. An attacker controlling one hop sees request patterns going out and response patterns coming back, enabling timing correlation between the two.

With unidirectional tunnels, your outbound hops see only outgoing traffic. Your inbound hops see only incoming traffic. The service's hops operate similarly. An attacker must control hops on multiple tunnels simultaneously to perform the same correlation, dramatically increasing the resources required for deanonymization.

Garlic routing mitigates the latency cost of four tunnels by bundling multiple functions into single transmissions. The acknowledgment that would otherwise require a separate round-trip travels with the next outgoing message. The LeaseSet update that would require a database query piggybacks on regular traffic. The system trades bandwidth for latency reduction, sending slightly larger messages less frequently rather than smaller messages more often.