Skip to main content

02 I2P

I2P (Invisible Internet Project) is a decentralized, garlic-routing overlay network designed primarily for anonymous hosting and in-network services (eepsites, IRC, file sharing). Unlike Tor, which focuses on reaching the clearnet anonymously, I2P is a self-contained network: destinations are reached through unidirectional tunnels built from a distributed NetDB, and most traffic never leaves the overlay.

CAUTION

Authorized Use Only.

I2P is legal in most jurisdictions and is used by privacy-conscious users, journalists, and developers. Running a router that participates in the network is normal; running an outproxy (exit to clearnet) carries the same legal considerations as running a Tor exit relay. Check your local laws before operating an outproxy. See ../../../SECURITY.md for the repository's authorized-use policy.

1. Overview​

I2P is a peer-to-peer overlay network that provides anonymous communication and hosting. Its design differs from Tor in several fundamental ways:

  • Unidirectional tunnels - each party builds separate inbound and outbound tunnels. A request and its response travel through different paths, exposing only half the traffic flow to any single observer.
  • Garlic routing - multiple messages ("cloves") are bundled into a single encrypted payload, making traffic analysis harder and improving throughput.
  • Distributed NetDB - network information is stored in a Kademlia DHT maintained by floodfill routers, not by a central directory authority.
  • Focus on in-network services - I2P is optimized for eepsites (.i2p sites), IRC, and file sharing inside the network, not for anonymous clearnet browsing (though outproxies exist).

What I2P is not:

  • Not a drop-in replacement for Tor. The threat model and the tooling are different; choosing the wrong network for a task is a common mistake.
  • Not a fast clearnet proxy. Outproxies are few, slow, and often unreliable.
  • Not a mixnet. Like Tor, it is a low-latency network and is therefore vulnerable to traffic correlation by a global passive adversary.

2. Threat Model​

Defends against:

  • Local network adversary (ISP, corporate proxy) - sees only encrypted I2P traffic to other routers, not the final destination.
  • Destination server - sees a tunnel endpoint, not the client's real router address.
  • Single-hop observation - a compromised router in a tunnel sees only the previous and next hop, not the full path.
  • Correlation of request and response - because inbound and outbound tunnels are separate, an adversary observing one direction does not see the other direction on the same path.

Does NOT defend against:

  • Global passive adversary (GPA) - an adversary who observes both ends can perform traffic correlation, as with Tor. Unidirectional tunnels raise the bar but do not eliminate the attack.
  • Predecessor attacks - if an adversary controls the first hop of a tunnel, they may learn the previous hop over time. I2P's peer selection strategies aim to mitigate this, but it remains a research area.
  • Malicious floodfill routers - floodfills store and serve NetDB data; a colluding set can attempt to eclipse a router's view of the network.
  • Endpoint compromise - malware on the client, a compromised browser, or a keylogger undermines the network entirely.
  • Outproxy logging - if you use an outproxy to reach clearnet, the outproxy operator sees your traffic (if unencrypted) and can log it.

Choice guidance:

  • Anonymous hosting (eepsites): I2P is the better choice. Tor onion services work, but I2P is purpose-built for in-network hosting.
  • Anonymous clearnet browsing: Tor is the better choice. I2P outproxies are limited.
  • Against a global adversary: neither network alone is sufficient; combine with operational discipline (section 6).

3. How It Works (technical)​

Network database (NetDB):

I2P maintains a distributed hash table (DHT) of two record types:

  • RouterInfo - a router's identity, addresses (IPv4/IPv6), TCP/UDP ports, and public keys. Published directly.
  • LeaseSet - a destination's tunnel endpoints, expiration time, and public key. Published anonymously through tunnels to avoid correlating the destination with the hosting router.

Floodfill routers (those with sufficient bandwidth and uptime) store and serve the NetDB using the Kademlia algorithm.

Tunnel construction:

I2P tunnels are unidirectional and short-lived (10 minutes):

Client -> Outbound Tunnel (Gateway -> Participant -> Endpoint) -> Network
Network -> Inbound Tunnel (Gateway -> Participant -> Endpoint) -> Client

Each tunnel is a sequence of 2-5 hops (default: 3).
Each hop is a router selected from the NetDB.

For a round-trip message, four tunnels are involved: the client's outbound, the client's inbound, the destination's outbound, and the destination's inbound.

Garlic routing:

I2P bundles multiple messages into a single "garlic" message. Each message is a "clove" with its own delivery instructions. The cloves are encrypted together with ElGamal/AES+SessionTag and are only separated at the tunnel endpoint.

This bundling serves three purposes:

  1. Traffic analysis resistance - the number and timing of cloves is not visible to intermediate hops.
  2. Efficiency - a single garlic message can carry multiple logical messages, amortizing per-message overhead.
  3. Reply blocks - the original sender can include a reply block ("garlic" to the destination) without exposing their identity.

Eepsites:

An eepsite is a service hosted inside I2P. It has a cryptographic destination (the long .b32.i2p address) and an optional human-readable name (.i2p) registered through the address book system.

Java I2P ships with Jetty, a lightweight Java webserver, pre-configured on 127.0.0.1:7658.

4. Installation and Setup​

Debian / Ubuntu (official repository):

# Add the official I2P PPA (Ubuntu) or repository (Debian)
# Ubuntu:
sudo apt-add-repository ppa:i2p-maintainers/i2p
sudo apt update
sudo apt install i2p

# Debian (official deb.i2p.net repository):
# See https://geti2p.net/en/download/debian for the current setup

Docker (recommended for isolation):

docker run -d \
  --name i2p \
  -e JVM_XMX=512m \
  -v i2pconfig:/i2p/.i2p \
  -p 127.0.0.1:7657:7657 \
  -p 127.0.0.1:4444:4444 \
  -e EXT_PORT=12345 \
  -p 12345:12345 \
  -p 12345:12345/udp \
  geti2p/i2p:latest

The EXT_PORT should be a random port above 1024, published for both TCP and UDP to allow incoming connections (improves network health and your own tunnel reliability).

Windows:

Use the official installer from https://geti2p.net/. For a hardened browser profile, the i2p.firefox project provides a pre-configured Firefox bundle with anti-fingerprinting and first-party isolation.

Router console:

After installation, open http://127.0.0.1:7657/ to access the router console. This is the control interface for all I2P services.

Post-install configuration:

  1. Bandwidth: the default is 96 KB/s down / 40 KB/s up. Raise it if your connection allows; higher bandwidth improves network health.
  2. NAT/firewall: forward the I2P ports (TCP and UDP) if you can.
  3. Inbound TCP: enable it in the configuration page if you have forwarded the port.

5. Hardening and Configuration​

Tunnel settings for eepsites:

In the Hidden Services Manager, the default tunnel length is 3 hops. For higher anonymity at the cost of latency, increase to 4-5 hops; for lower latency, reduce to 2 (not recommended for high-threat models).

  • Tunnel length: 3 hops default. More hops = more anonymity, slower.
  • Tunnel quantity: 2 inbound / 2 outbound default. Increase for high-traffic sites; decrease to save resources.
  • Tunnel variation: 0 default. Set to 0-1 to randomize length.

Client configuration (router.config):

# Reduce information leakage
i2np.ntcp.disable = false
i2np.ssu.disable = false

# Disable unnecessary services
i2p.inproxy.disable = true
i2p.socks.outproxy.disable = true

Browser hardening:

  • Use the I2P Browser profile (Firefox) or the i2p.firefox bundle rather than a normal browser pointed at the proxy.
  • Configure the browser to use the HTTP proxy at 127.0.0.1:4444 (or the HTTPS proxy at 4445).
  • Do not browse clearnet and I2P in the same browser session.
  • Set the browser language, timezone, and User-Agent consistently; mismatched values are a fingerprint.

System hardening:

  • Never run I2P and Tor in the same browser session. Use separate browsers or separate VMs.
  • Use a dedicated VM or container for I2P if your threat model warrants it. The Docker setup above provides basic isolation.
  • Disable the outproxy unless you specifically need clearnet access through I2P. Outproxies see your traffic.
  • Keep the router updated. I2P releases security fixes regularly.

Router identity:

Your router's identity (the router.keys file) is the cryptographic anchor of your I2P presence. Back it up if you run a service; losing it means losing your eepsite address.

6. Operational Usage​

Accessing eepsites:

I2P sites are reachable through the HTTP proxy on 127.0.0.1:4444. The .i2p name resolution is handled by the local address book (a subscription-based system), not by DNS.

# curl through the I2P HTTP proxy
curl -x http://127.0.0.1:4444 http://<name>.i2p/

# Using the b32 address directly (no address book needed)
curl -x http://127.0.0.1:4444 http://<52-char-b32>.b32.i2p/

Running an eepsite (Jetty):

  1. Open the Hidden Services Manager at http://127.0.0.1:7657/i2ptunnelmgr.
  2. The pre-configured "I2P webserver" entry is ready but stopped.
  3. Click it, set a name and description, check "Auto Start Tunnel".
  4. Leave the target as 127.0.0.1:7658 unless you run a custom server.
  5. Start the tunnel; the .b32.i2p address appears in the manager.
  6. Place content in ~/.i2p/eepsite/docroot/ (or the configured docroot directory).

Registering a .i2p name:

Human-readable names are managed by the address book system. You can publish your own address book entry or request registration in a public address book. This is a trust-based system, not a global namespace.

Using I2P for IRC:

I2P has built-in IRC and SMTP/POP3 proxies (ports 6668, 7659, 7660 in the Docker image). Configure your client to use the appropriate proxy.

I2PSnark (BitTorrent):

Java I2P includes I2PSnark, a BitTorrent client that operates entirely inside I2P. This is the intended use case for file sharing on I2P - never use a clearnet BitTorrent client over I2P.

7. Common Mistakes​

  • Using I2P as a Tor replacement for clearnet browsing. Outproxies are few, slow, and often down. Use Tor for clearnet; use I2P for in-network services.
  • Running a clearnet BitTorrent client over I2P. The client leaks your real IP through DHT, trackers, and peer exchange. Use I2PSnark.
  • Mixing I2P and clearnet identities. A name used on an eepsite must never be linked to a clearnet account.
  • Assuming unidirectional tunnels defeat a global adversary. They raise the bar but do not eliminate traffic correlation.
  • Leaving the outproxy enabled by default. Outproxies see your traffic and can log it. Disable unless needed.
  • Forgetting to forward UDP. I2P uses both TCP and UDP (SSU2). Forwarding only TCP degrades your connectivity and network health.
  • Running on low bandwidth with default settings. The defaults (96/40 KB/s) are conservative; raising them improves your own tunnel reliability and the network.
  • Losing the router keys. If you run a service, back up router.keys and the eepsite private keys.
  • Using a normal browser pointed at the proxy. Fingerprinting (canvas, fonts, timezone, language) can link sessions. Use the I2P Browser profile.
  • Assuming eepsites are globally unique by name. The address book is local and trust-based; different users may map the same name to different destinations.

8. Attacks Against It​

Traffic analysis and correlation:

  • End-to-end correlation. A global passive adversary who observes both the client's outbound tunnel and the destination's inbound tunnel can correlate timing and volume. Unidirectional tunnels require observing two separate paths, raising the bar.
  • Website fingerprinting. An adversary observing the client's outbound traffic can attempt to classify the eepsite being visited. I2P's traffic patterns are less regular than Tor's, which some research suggests makes classification harder in some scenarios and easier in others.
  • Predecessor attacks. An adversary who controls a tunnel hop can attempt to learn the previous hop over repeated tunnel constructions. I2P's peer selection aims to mitigate this.

NetDB attacks:

  • Eclipse attack. A colluding set of floodfill routers can attempt to isolate a router from the honest NetDB, feeding it false information.
  • Sybil floodfills. An adversary running many floodfills increases the chance of being queried for NetDB data.
  • LeaseSet correlation. Because LeaseSets are published anonymously, correlating a LeaseSet with its hosting RouterInfo is the key challenge for an adversary.

Outproxy attacks:

  • Outproxy logging. The outproxy operator sees all clearnet destinations and, if the traffic is unencrypted, the content.
  • Outproxy compromise. A compromised outproxy can inject content or redirect traffic.
  • Outproxy blocklisting. Many clearnet sites block known I2P outproxy IPs.

Client-side attacks:

  • Browser exploits. A malicious eepsite can exploit a browser vulnerability. Use a hardened browser profile.
  • Malicious eepsites. Eepsites can serve malicious content just like clearnet sites. Treat them as untrusted.
  • Router exploits. The I2P router itself is a Java application; vulnerabilities in Java or the router code can compromise the host.

9. Detection (Blue Team)​

Network-level detection:

  • Known I2P ports. TCP/UDP 9000-31000 (configurable). The default range is broad; blocking the entire range is disruptive.
  • NTCP2/SSU2 fingerprint. I2P's transport protocols have recognizable handshake patterns. DPI boxes can classify them.
  • Traffic volume and timing. I2P traffic is bidirectional and relatively constant (tunnels, NetDB maintenance), unlike request-response browsing.
  • Reseed domains. A fresh router queries hardcoded reseed domains over HTTPS. Blocking these domains prevents bootstrap.

Host-level detection:

  • Process names. i2prouter, java running router.jar, i2psvc (system service).
  • Local ports. 7657 (console), 4444 (HTTP proxy), 4445 (HTTPS proxy), 7658 (eepsite), 6668 (IRC proxy).
  • File artifacts. ~/.i2p/ (Linux), %APPDATA%\I2P\ (Windows), router.keys, netDb/.
  • Docker containers. The geti2p/i2p image name and the i2pconfig volume are visible to container monitoring.

Detection in an enterprise (MITRE T1090.003):

Y-Security's DET0359 provides detection analytics for multi-hop proxy behavior including I2P:

  • Process creation: monitor for proxy/anonymity tools spawning from unusual parents (e.g., mshta spawning a Java process).
  • Network connections: sustained encrypted outbound traffic to known anonymity infrastructure; connections to multiple nodes in short succession.
  • DNS: outbound resolution to known reseed domains or .i2p lookups (though I2P names are resolved locally, not via DNS).
  • Relay count: more than 2 outbound IPs contacted in rapid succession without DNS resolution is abnormal for most services.

False positives: developers testing I2P integrations, privacy researchers, and users in censored regions use I2P legitimately. Detection should inform policy, not trigger automatic blocking.

10. Case Studies​

Case 1 - Silk Road Reloaded (2015). After Silk Road was taken down, a successor ("Silk Road Reloaded") was hosted on I2P. The operator was identified through operational mistakes, not through breaking I2P. Public reporting at the time noted that I2P's design made network-level deanonymization harder than Tor, but endpoint and operational security remained the weak point.

Case 2 - I2P as a censorship circumvention tool. I2P is used in regions with heavy internet censorship because its decentralized NetDB has no central directory to block. Blocking I2P requires blocking a broad port range and reseed domains, which is disruptive and easily bypassed with bridges (though I2P's reseed mechanism is different from Tor's bridges).

Case 3 - I2P in malware. Some malware families (e.g., certain ransomware) have used I2P for command-and-control because it is decentralized and has no central points to seize. This is a case where the network's design (no central authority) complicates takedown.

Common pattern: As with Tor, public cases of I2P-related deanonymization tend to involve operational mistakes, endpoint compromise, or correlation - not breaking the network's cryptography.

Client use:

  • Legal in most jurisdictions. Not explicitly blocked in as many countries as Tor, but the same legal principles apply: I2P does not legalize illegal content.
  • Using I2P to access content illegal in your jurisdiction is still illegal.

Router operation:

  • Participating router (default): low legal risk. Your router relays traffic for others, but you are not the exit.
  • Floodfill router: higher bandwidth and uptime requirements; no additional legal risk in most jurisdictions.
  • Outproxy: this is the I2P equivalent of a Tor exit relay. You are the visible source of clearnet traffic. Check your jurisdiction's laws and your ISP's AUP before running one.

Ethical considerations:

  • I2P is used by journalists, activists, and ordinary users for legitimate privacy. Do not assume malicious intent.
  • Do not use I2P to evade lawful investigation, traffic illegal material, or harm others.
  • See ../../../SECURITY.md for the repository's authorized-use policy.

12. Production Notes​

For a red team engagement:

  • I2P is rarely the right tool for an authorized engagement. Corporate networks often block it, and its use may violate the rules of engagement.
  • If anonymity is required, use a dedicated infrastructure (VPS + VPN) and document it in the engagement plan.

For personal threat modeling:

  • Use I2P Browser (or the i2p.firefox bundle) for browsing, not a normal browser pointed at the proxy.
  • Keep the router updated. Update through the built-in updater or the package manager.
  • Use a dedicated VM or container if your threat model includes endpoint compromise.
  • Do not mix I2P with personal accounts or clearnet identities.

For running an eepsite:

  • Back up router.keys and the eepsite private key (eepsite/eepPriv.dat). Losing them means losing your address.
  • Monitor the router console for tunnel health.
  • Set the tunnel length based on your threat model (3 is the default; 4-5 for higher anonymity).
  • For high-traffic sites, increase tunnel quantity (3/3 or more) and bandwidth allocation.

For running a reseed server:

  • Reseed servers distribute the initial NetDB to new routers.
  • Use reseed-tools (Go) with a signed SU3 file.
  • Back up the signing keys in /home/i2p/.reseed/; they are essential for operation.
  • Run behind a reverse proxy (Nginx) for TLS termination.

13. References​