I2P (Invisible Internet Project)
I2P is an anonymous network layer that provides pseudonymous peer-to-peer communication.
What is I2P?
I2P (Invisible Internet Project) is an anonymous network layer released in 2003 by a community of developers. Unlike Tor, which is designed primarily for exiting to the clearnet, I2P focuses on internal hidden services and peer-to-peer communication within the network. Users run I2P routers that participate in the network by forwarding traffic for other users, earning bandwidth credits that allow them to consume network resources.
The network is entirely peer-to-peer with no central servers or directories. All routing information is distributed through the Network Database (NetDb). I2P is optimized for latency-tolerant, bulk-transfer applications rather than low-latency interactive sessions.
Garlic Routing
I2P uses garlic routing (named for the garlic clove structure with multiple layers). Unlike Tor's onion layers, I2P bundles multiple messages together in a single garlic clove. This makes traffic analysis significantly harder because a single packet contains data for multiple destinations.
Key properties of garlic routing:
- Message bundling: Multiple encrypted messages combined in one garlic clove
- Layered encryption: Each message has its own independent encryption
- Tagging: Messages include delivery instructions and expiration times
- Accumulated ACKs: Acknowledgments bundled with outbound messages to reduce overhead
Tunnel Building
I2P creates unidirectional tunnels (inbound or outbound) rather than bidirectional circuits like Tor. This means a complete communication requires two tunnels: one from client to service, one from service to client.
Tunnel Creation Process
- Client selects peers as tunnel participants (typically 2-3 hops)
- Client encrypts layering information with each peer's public key
- Tunnel is built incrementally, layer by layer, from the furthest hop back
- Each peer knows only its predecessor and successor
- Tunnels expire after 10-20 minutes and are rebuilt to prevent traffic analysis
Tunnel Types
- Exploratory tunnels: Short-lived tunnels for network database lookups and network operations
- Client tunnels: Longer-lived tunnels used for application traffic
- Inbound tunnels: Receive data from the network to the endpoint
- Outbound tunnels: Send data from the endpoint to the network
Network Database (NetDb)
I2P maintains a distributed database of router info and lease sets. The NetDb is distributed via a dedicated floodfill network (high-capacity nodes that store and serve routing information).
- Router Info: Contains a peer's public keys, transport addresses (for SSU and TCP), and metadata. Signed with the router's identity key.
- Lease Set: Contains the tunnel entry points for a hidden service (how to reach a destination). Includes the service's encryption public key and a list of inbound tunnel gateways with their expiration times.
- Meta Lease Sets: Indirect routing through ablized gateway
New peers discover each other through floodfill routers using a distributed hash table (DHT) approach, with a Modified Kademlia algorithm adapted for I2P's threat model.
Encryption Stack
I2P uses multiple independent layers of encryption:
- ECIES-X25519: Elliptic curve integrated encryption scheme with X25519 key exchange for end-to-end encryption between peers
- ElGamal/AES+Session Tags (deprecated): Previously used for end-to-end encryption; replaced due to performance
- Tunnel encryption: Layered AES-256 encryption for each tunnel hop. Each tunnel endpoint encrypts to the next hop.
- Transport encryption: DTLS for SSU (UDP-like transport), TLS for TCP-like streaming library
- Signing: Ed25519 for message authentication and identity
Transports
SSU (Simple Secure UDP)
The primary UDP transport. SSU includes:
- Peer testing ( NAT detection and peer discovery)
- Introduction (handshake and session establishment)
- Fragmentation and reassembly for large messages
- Ack packets for reliable delivery
TCP
I2P also supports TCP transport for environments where UDP is blocked. TCP transport is less efficient but more reliable in restrictive networks.
SSU2 (2021+)
Newer UDP transport with:
- Noise Protocol Framework for key exchange
- ChaCha20-Poly1305 for authenticated encryption
- Improved NAT traversal
- Reduced overhead compared to original SSU
Eepsites (I2P Hidden Services)
I2P's equivalent of Tor onion services are called eepsites. They provide anonymous servers within the I2P network. The service:
- Generates a destination (public/private key pair and encryption key)
- Creates inbound tunnels to receive requests
- Publishes its lease set to the NetDb
- Clients look up the lease set and connect through their own outbound tunnel to the eepsite's inbound tunnel
Eepsite addresses end in .i2p (I2P's namespace). These are derived from the destination's Base64-encoded hash, similar to Tor's onion addresses.
Applications on I2P
- I2P-Bote: Distributed, anonymous email system with end-to-end encryption
- I2PSnark: Built-in BitTorrent client optimized for I2P
- Susimail: Web-based email client for I2P-Bote
- I2P IRC: Anonymous IRC network within I2P
- Torrent-tracker: I2P has its own distributed tracker
Comparison: I2P vs Tor
| Aspect | I2P | Tor |
|---|---|---|
| Primary use | Internal services, P2P | Clearnet exit, bidirectional |
| Routing | Unidirectional garlic tunnels | Bidirectional onion circuits |
| Exit nodes | No (internal only) | Yes |
| Tunnel lifetime | 10-20 minutes | circuits typically longer |
| Message bundling | Yes (garlic cloves) | No (single relay cells) |
| Network size | Smaller (~50k-100k routers) | Larger (~7k relays) |
| Throughput | Moderate | Moderate to high |