Was ist I2P?
01 / 05Ein Netz im Netz
I2P — Invisible Internet Project — ist eine Overlay-Netzwerkschicht, die vollständig innerhalb des regulären Internets betrieben wird, aber von außen unsichtbar bleibt. Anders als Tor ist I2P primär nicht darauf ausgelegt, das normale Web anonym zu erreichen — sondern ein eigenes, abgeschlossenes Netzwerk mit eigenen Diensten zu bilden.
Jeder I2P-Knoten ist gleichzeitig Client, Server und Relay. Es gibt keine feste Hierarchie, keine Directory Authorities, keine zentralen Verzeichnisserver. Das Netzwerk ist vollständig peer-to-peer und selbstorganisierend.
Das Projekt existiert seit 2003, ist in Java geschrieben und läuft als eigenständige Anwendung mit einem lokalen Webinterface. Der gesamte Quellcode ist frei und unter verschiedenen Open-Source-Lizenzen verfügbar.
kein zentraler Server
Garlic Routing
02 / 05Nachrichten wie Knoblauch
I2P nutzt Garlic Routing — eine Weiterentwicklung des Onion-Routing-Prinzips von Tor. Der Unterschied: mehrere verschlüsselte Nachrichten werden zu einem „Knoblauch-Bündel" zusammengepackt und gemeinsam durch das Netzwerk geleitet.
Das erschwert Traffic-Analyse erheblich: ein Beobachter kann nicht einfach einzelne Pakete verfolgen, weil er nicht weiß, wie viele Nachrichten im Bündel stecken oder für wen sie bestimmt sind.
Verschlüsselung erfolgt Ende-zu-Ende zwischen Sender und Empfänger — zusätzlich zur Tunnel-Verschlüsselung auf jeder Relay-Schicht. Zwei unabhängige Verschlüsselungsebenen gleichzeitig.
In & Out getrennt
Das wichtigste strukturelle Merkmal von I2P gegenüber Tor: Eingehender und ausgehender Traffic nutzen separate Tunnel in entgegengesetzter Richtung.
In Tor läuft ein Circuit bidirektional — Anfrage und Antwort durch denselben Kanal. In I2P baut der Client einen Outbound-Tunnel für Anfragen und der Zieldienst einen Inbound-Tunnel für Antworten. Beide Pfade sind unabhängig.
Selbst wenn ein Angreifer einen Tunnel kompromittiert, sieht er nur eine Richtung des Traffics — eine erhebliche Erschwernis für Korrelationsangriffe.
// Beide Tunnel treffen sich an einem Rendezvous-Knoten. Sender und Empfänger kennen nur ihren eigenen Tunnelpfad.
Dienste im I2P-Netz
03 / 05
I2P-Dienste heißen Eepsites und sind über
.i2p-Adressen erreichbar — ausschließlich innerhalb des I2P-Netzwerks.
Sie sind nicht aus dem normalen Internet zugänglich und nicht indexierbar.
Eepsites (.i2p)
Interne Websites, nur im I2P-Netz erreichbar. Kein DNS, keine IP-Preisgabe, nicht aus dem Clearnet zugänglich.
I2P-Bote
Dezentrales, serverless E-Mail-System vollständig innerhalb I2P. Nachrichten werden über das P2P-Netz zugestellt, kein zentraler Mailserver.
I2P-Messenger (XMPP)
Jabber/XMPP-basierte Kommunikation über I2P-Tunnel. Vollständig verschlüsselt, kein zentraler Server erforderlich.
I2PSnark (BitTorrent)
Integrierter BitTorrent-Client, der ausschließlich über I2P-Tunnel operiert. Kein Exit-Node nötig, vollständig intern.
Outproxy (Clearnet)
Optionaler Zugang zum normalen Internet über I2P-Outproxies — analog zu Tor Exit-Nodes, aber nicht der primäre Zweck.
Addressbook
Dezentrales, abonnierbares Verzeichnis für .i2p-Adressen. Kein DNS — Verzeichnisse werden P2P geteilt und lokal gepflegt.
Tor bringt dich anonym ins bestehende Internet.
I2P baut ein neues Netz —
eines, das von Grund auf so entworfen wurde,
dass Überwachung strukturell unmöglich ist.
I2P vs. Tor vs. VPN
04 / 05| Eigenschaft | I2P | Tor | VPN |
|---|---|---|---|
| Primärer Zweck | Internes anonymes Netz | Anonymer Zugang zum Clearnet | Privacy & Geo-Umgehung |
| Architektur | Vollständig P2P, dezentral | Relays + Directory Authorities | Zentraler Server (1 Hop) |
| Routing | Garlic Routing, unidirektionale Tunnel | Onion Routing, 3-Hop-Circuit | Direkt zu VPN-Server |
| Clearnet-Zugang | Outproxy, eingeschränkt | Ja, via Exit-Node | Ja, primärer Zweck |
| Interne Dienste | Vollständiges Ökosystem | Hidden Services (.onion) | Nein |
| Traffic-Analyse-Resistenz | Sehr hoch (getrennte Tunnel) | Hoch (3 Hops) | Gering |
| Einstiegshürde | Hoch (Java, eigenes Ökosystem) | Niedrig (Tor Browser) | Niedrig |
| Geschwindigkeit | Langsam | Mittel | Hoch |
| Vertrauensmodell | Kein zentrales Vertrauen nötig | Directory Authorities (9 Server) | Vollständiges Vertrauen in Anbieter |
Ehrliche Einschätzung
05 / 05- Höchste strukturelle Resistenz gegen Traffic-Korrelation durch getrennte Tunnel
- Vollständig dezentral — kein zentraler Angriffspunkt, keine Directory Authorities
- Reiches internes Ökosystem: Mail, Chat, Filesharing, Websites ohne Clearnet-Abhängigkeit
- Jeder Knoten stärkt das Netz — keine Freifahrer, alle Nutzer routen Traffic für andere
- Keine Exit-Node-Problematik für interne Dienste — alles bleibt im Netz
- Garlic Routing macht Paketanalyse strukturell schwieriger als bei Tor
- Sehr hohe Einstiegshürde — Java-Abhängigkeit, komplexe Konfiguration, eigenes Ökosystem
- Kleines Netzwerk (~50k Knoten) — anfälliger für Sybil-Angriffe als Tor
- Clearnet-Zugang über Outproxies eingeschränkt und nicht zuverlässig
- Deutlich langsamer als Tor, kaum für browsing-intensive Nutzung geeignet
- Dokumentation lückenhaft, Community kleiner als Tor-Ökosystem
- Java als Laufzeitumgebung: höherer Ressourcenverbrauch, größere Angriffsfläche
- Schlechte GrapheneOS/Android-Integration —
i2pdals C++-Alternative existiert, aber weniger ausgereift
Für wen ist I2P das richtige Werkzeug?
I2P ist kein Ersatz für Tor — es ist ein anderes Werkzeug für ein anderes Bedrohungsmodell. Wer primär anonym das normale Web surfen will, ist mit Tor besser bedient.
I2P ist dann die richtige Wahl, wenn das Ziel ein vollständig abgeschlossenes, zensurresistentes Kommunikationssystem ist — ein Netz innerhalb des Netzes, das auch dann funktioniert, wenn das Clearnet gesperrt oder feindlich ist. Filesharing, interne Kommunikation, zensurresistente Publikationen — das ist das Terrain von I2P.
Für den Alltag auf GrapheneOS oder Linux ist der Einstieg über i2pd
(C++-Implementierung) realistischer als die Java-Variante.
Der Aufwand ist erheblich — der Nutzen entsprechend spezifisch.