I2P ist ein Projekt, welches ein Netzwerk zum sicheren und anonymen Kommunizieren planen, aufbauen und betreuen wird. Nutzer von I2P haben die Kontrolle über die Verteilung zwischen Anonymität, Verlässlichkeit, genutzter Bandbreite und Verzögerung. Es gibt keinen zentralen Punkt im Netzwerk, welcher übernommen werden kann um die Integrität, Sicherheit oder Anonymität des Systems zu komprimieren. Das Netzwerk kann sich in einer Reaktion auf Angriffe selber rekonfiguriern und wurde so geplant, das es zusätzliche Ressourcen bei deren Verfügbarkeit nutzen wird. Selbstverständlich sind alle Aspekte des Netzwerkes offen und frei verfügbar.
Im Gegensatz zu vielen anderen anonymen Netzwerken versucht I2P nicht die Anonymität durch verstecken eines Teils einer Kommunikation, der Sender oder der Empfänger, herzustellen. I2P wurde so geplant, das Nutzer von I2P untereinander anonym kommunizieren können - Sender und Empfänger sind für den jeweils anderen anonym als auch für nicht beteiligte dritte. Zum Beispiel gibt es zur Zeit I2P interne Webseiten (die anonymes Publizieren/hosten erlauben) und einen HTTP Proxy in das normale Internet (der anonymes Browsing bietet). Server im I2P Netz betreiben zu können ist eine essentielle Angelegenheit, da angenommen werden kann, das die Proxis ins normale Internet überwacht werden, abgeschaltet werden oder gar zu schlimmeren Angriffen genutzt werden.
Das Netzwerk selber ist Nachrichten basiert - es ist essentiell eine sichere und anonyme IP Schicht, in der Nachrichten an kryptographische Schlüssel (Ziele) geschickt werden;die Nachrichten selber können signifikant grösser als IP Pakete werden. Beispiele für die Nutzung des Netzwerkes sind unter anderem "Eepsites" (Webserver mit normalen Webapplikationen innerhalb von I2P), ein BitTorrent Klient ("I2Psnark") oder ein verteilter Datencontainer. Mit der Hilfe von mihis I2PTunnel Applikation können wir die üblichen TCP/IP Anwendungen über I2P tunneln, z.B. SSH, IRC, ein squid Proxy oder gar Audio. Viele Leute werden I2P nicht direkt nutzen oder nicht bemerken, das sie I2P nutzen. Stattdessen sehen sie nur eine der I2P fähigen Anwendungen oder nur eine Einstellung für verschiedene Proxies, die ihnen Anonyme Verbindungen anbieten.
Ein wichtiger Teil des Planens, Entwickelns und Testens eines anonymen Netzwerkes ist das Definieren des Angriffsszenarios, da es "echte" Anonymität nicht gibt, nur steigende Kosten und. Aufwand jemanden zu identifizieren. Kurz gesagt: I2P Absicht ist es, Personen in willkürlichen feindseligen Umgebungen einen militärischen Grad der Anonymität zu bieten, versteckt in dem hinreichendem Datenstrom aus der Aktivität anderer Leute, die weniger Anonymität benötigen. Dieses beinhaltet den Chat von Joe Sixpack mit seinen Freuden, den niemanden mitlesen kann, Jane Filesharer, die wei?~_ das die grossen Konzerne sie beim Tauschen von Dateien nicht identifizieren können, als auch Will Geheimnisverräter, der geheime Dokumente veröffentlicht - alles in dem selben Netzwerk, in dem eine Nachricht nicht von einer anderen unterschieden werden kann.
Warum?
There are a multitude of reasons why we need a system to support anonymous communication, and everyone has their own personal rationale. There are many other efforts working on finding ways to provide varying degrees of anonymity to people through the Internet, but we could not find any that met our needs or threat model.
Wie?
In einer übersicht existiert das Netzwerk aus einer Gruppe von Knoten ("Router") mit einer Anzahl an unidirektionalen virtueller Eingangs und Ausgangs Wege ("Tunnel", wie in der Tunnel Routing Seite beschrieben). Jeder Router wird duch eine kryptographische RouterIdentity eindeutig indentifiziert, diese ist für gewöhnlich dauerhaft gültig. Diese Router kommunizieren über vorhandene Übertragungsmechanismen (TCP, UDP, etc.) und tauschen verschiedene Nachrichten aus. Klientprogramme haben ihre eigenen kryptographischen Ident ("Ziel"), durch den sie zum Senden und Empfangen von Nachrichten befähigt sind. Diese Klienten können zu irgendwelchen Routern Verbindung aufnehmen und authorisieren ihre derzeitige Belegung ("lease") von ein paar Tunneln, die zum Senden und Empfangen von Nachrichten durch das Netzwerk benutzt werden. I2P hat eine eigene Netzwerk Datenbank ("verwendet eine Modifikation des Kademlia-Algorithmus") zum skalierbaren sicherem Verteilen von Routing und Kontaktinformationen.
Im oberen Bild betreiben Alice, Bob, Charlie und Dave je einen Router mit einer einzigen Destination auf ihren lokalen Router. Sie haben alle ein paar 2-Hop Eingangstunnel je Destination (mit 1, 2, 3, 4, 5 und 6 bezeichnet) und ein paar haben 2-Hop Ausgangstunnel. Zur Vereinfachung sind Charlies Eingangstunnel und Daves Ausgangstunnel nicht eingezeichnet, ebenso wie weitere Ausgangstunnel der Router (normalerweise so 5-10 Tunnel gleichzeitig). Sobald Alice und Bob miteiander reden, sendet Alice eine Nachricht über ihren (pinken) Ausgangstunnel in Richtung eines vons Bobs Eingangstunneln (grün, Tunnel 3 oder 4). Sie lernt den Eingangstunnel durch eine Abfrage der Netzwerk Datenbank kennen, diese Datenbank wird dauerhaft aktualisiert sobald neue Leases authorisiert sind und ältere auslaufen.
Antwortet Bob nun Alice, geschieht dieses auf der selben Art und Weise - er sendet eine Nachricht über einen seiner Ausgangstunnel in Richtung eines von Alice Eingangstunnels (Tunnel 1 oder 2). Um vieles einfacher zu machen, sind viele Nachrichten zwischen Bob und Alice in sogenannte "Garlics" eingepackt, in denen die Lease Information vom Sender enthalten ist, so das der Empfänger sofort antworten kann ohne in der Netzwerk Datenbank nach den benötigten Informationen suchen zu müssen.
Um einigen Attacken aus dem Wege zu gehen ist I2P dezentral aufgebaut, ohne eine zentrale Instanz - und wie schon richtig geraten existiert kein zentraler Verzeichnisdienst, der Informationen zur Performance und Kontinuität der Router im Netzwerk verwaltet. Daraus folgt, da?~_jeder Router eigene Profile verschiedener Router halten und pflegen muss. Ebenso ist jeder Router selber verantwortlich für die Auswahl der korrekten Knoten um die Anforderungen an die Anonymität, Performance und Konitnuität des Benutzers zu erfüllen, so wie es in der "Knoten Auswahl" Seite beschrieben ist.
Das Netzwerk selber nutzt eine signifikante Anzahl von Kryptographischen Techniken und Algorhytmen - die Liste umfässt 2048bit ElGamal Verschlüsselung, 256bit AES im CBC Modus mit PKCS#5 Padding, 1024bit DSA Signaturen, SHA256 Hashes, 2048bit Diffie-Hellmann vermittelte Verbindungen mit Station-zu-Station Authentifizierung und ElGamal / AES+SessionTag.
Daten die über I2P gesendet werden, durchlaufen 3 Verschlüsselungen: garlic Verschlüsselung (zur überprüfung ob die Nachrichten beim Empfänger angekommen ist), Tunnelverschlüsselung (alle Nachrichten, die durch einen Tunnel gehen, sind vom Tunnel-Gateway bis zum Tunnelendpunkt verschlüsselt) und Zwischen-den-Routern-Übertragungsschicht Verschlüsselung (z.B. benutzt die TCP-Übertragung AES256 mit Ephemeral Schlüssel).
End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to Bob's router "h" remains. Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.
Die genaue Anwendung dieser Algorhytmen sind woanders beschrieben.
Die zwei Hauptbestandteile für den militärischen Grad der Anonymität sind explizite, verzögerte garlic geroutete Nachrichten und mehr umfassende Tunnel mit Unterstützung von Pooling und Mixen von Nachrichten. Diese Funktionen sind zur Zeit für Version 3.0 geplant, aber garlic geroutete Nachrichten mit keiner Verzögerung und FIFO Tunnels sind schon implementiert. Zusätzlich wird die Version 2.0 den Leuten erlauben, I2P hinter beschränkten Routen (möglicherweise mit vertrauten Knoten) aufzusetzen und zu betreiben; ebenso werden die flexiblere und anonymere Übertragungen eingebaut werden.
Some questions have been raised with regards to the scalability of I2P, and reasonably so. There
will certainly be more analysis over time, but peer lookup and integration should be bounded by
O(log(N)) due to the network database's algorithm, while end
to end messages should be O(1) (scale free), since messages go out K hops through the
outbound tunnel and another K hops through the inbound tunnel, with K no longer than 3. The size of
the network (N) bears no impact.
Wann?
I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use alternate transports, such as JMS, then grew into its own as an 'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest starting in August '03. I2P is currently under development, following the roadmap.
Wer?
We have a small team spread around several continents, working to advance different aspects of the project. We are very open to other developers who want to get involved and anyone else who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled applications, or documentation. The entire system is open source - the router and most of the SDK are outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel and I2PSnark are GPL. Almost everything is written in Java (1.5+), though some third party applications are being written in Python and other languages. The code works on Sun Java SE and other Java Virtual Machines.
Wo?
Anyone interested should join us on the IRC channel #i2p-dev (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.echelon.i2p, irc.dg.i2p and irc.oftc.net). There are currently no scheduled development meetings, however archives are available.
The current source is available in git.