I2P: Technische Einführung

HINWEIS: Dieses Dokument wurde ursprünglich von jrandom im Jahr 2003 verfasst. Obwohl wir uns bemühen, es aktuell zu halten, können einige Informationen veraltet oder unvollständig sein. Die Abschnitte zu Transport und Kryptographie sind Stand 2025-01 aktuell.

Einführung

I2P ist eine skalierbare, selbstorganisierende, widerstandsfähige paketvermittelte anonyme Netzwerkschicht, auf der eine beliebige Anzahl verschiedener anonymitäts- oder sicherheitsbewusster Anwendungen betrieben werden kann. Jede dieser Anwendungen kann ihre eigenen Kompromisse zwischen Anonymität, Latenz und Durchsatz treffen, ohne sich um die ordnungsgemäße Implementierung eines freien Route-Mixnets kümmern zu müssen, wodurch sie ihre Aktivitäten mit der größeren Anonymitätsmenge von Benutzern vermischen können, die bereits auf I2P laufen.

Bereits verfügbare Anwendungen bieten die gesamte Bandbreite typischer Internet-Aktivitäten — anonymes Web-Browsing, Web-Hosting, Chat, Dateiaustausch, E-Mail, Blogging und Content-Syndikation, sowie verschiedene andere Anwendungen, die sich in der Entwicklung befinden.

Web-Browsing: mit jedem bestehenden Browser, der die Nutzung eines Proxy unterstützt.
Chat: IRC und andere Protokolle
Dateiaustausch: I2PSnark und andere Anwendungen
E-Mail: susimail und andere Anwendungen
Blog: mit jedem lokalen Webserver oder verfügbaren Plugins

Im Gegensatz zu Websites, die in Content-Distribution-Netzwerken wie Freenet oder GNUnet gehostet werden, sind die auf I2P gehosteten Dienste vollständig interaktiv — es gibt traditionelle webähnliche Suchmaschinen, Diskussionsforen, Blogs, auf denen Sie kommentieren können, datenbankgesteuerte Sites und Brücken, um statische Systeme wie Freenet abzufragen, ohne es lokal installieren zu müssen.

Mit all diesen anonymitätsfähigen Anwendungen übernimmt I2P die Rolle der nachrichtenorientierten Middleware — Anwendungen geben an, dass sie Daten an eine kryptografische Kennung (eine “destination”) senden möchten, und I2P sorgt dafür, dass diese sicher und anonym dort ankommen. I2P bündelt auch eine einfache Streaming -Bibliothek, um I2Ps anonyme Best-Effort-Nachrichten als zuverlässige, geordnete Streams zu übertragen und bietet transparent einen TCP-basierten Überlastungskontrollalgorithmus, der auf das hohe Bandbreiten-Verzögerungsprodukt des Netzwerks abgestimmt ist. Während mehrere einfache SOCKS-Proxies verfügbar waren, um bestehende Anwendungen in das Netzwerk einzubinden, war ihr Nutzen begrenzt, da nahezu jede Anwendung routinemäßig Informationen preisgibt, die in einem anonymen Kontext sensibel sind. Der einzig sichere Weg ist, eine Anwendung vollständig zu auditieren, um den ordnungsgemäßen Betrieb sicherzustellen, und um dabei zu helfen, stellen wir eine Reihe von APIs in verschiedenen Sprachen zur Verfügung, die verwendet werden können, um das Beste aus dem Netzwerk herauszuholen.

I2P ist kein Forschungsprojekt — weder akademisch, kommerziell noch staatlich — sondern vielmehr eine technische Entwicklung, die darauf abzielt, alles Notwendige zu tun, um ein ausreichendes Maß an Anonymität für diejenigen zu bieten, die sie benötigen. Es befindet sich seit Anfang 2003 in aktiver Entwicklung mit einem Vollzeit-Entwickler und einer engagierten Gruppe von Teilzeit-Mitwirkenden aus aller Welt. Alle Arbeiten an I2P sind quelloffen und frei verfügbar auf der Website , wobei der Großteil des Codes direkt in die öffentliche Domäne freigegeben wird, obwohl einige kryptographische Routinen unter BSD-ähnlichen Lizenzen verwendet werden. Die Personen, die an I2P arbeiten, kontrollieren nicht, unter welchen Lizenzen andere Client-Anwendungen veröffentlichen, und es gibt mehrere GPL-lizenzierte Anwendungen (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex und andere). Die Finanzierung für I2P stammt vollständig aus Spenden und erhält derzeit keine Steuererleichterungen in irgendeiner Rechtsordnung, da viele der Entwickler selbst anonym sind.

Betrieb

Überblick

Um die Funktionsweise von I2P zu verstehen, ist es wichtig, einige Schlüsselkonzepte zu begreifen. Erstens trennt I2P strikt zwischen der am Netzwerk teilnehmenden Software (einem “router”) und den anonymen Endpunkten (“destinations”), die einzelnen Anwendungen zugeordnet sind. Die Tatsache, dass jemand I2P betreibt, ist normalerweise kein Geheimnis. Was verborgen bleibt, sind Informationen darüber, was der Nutzer tut, falls überhaupt etwas, sowie welcher router mit einer bestimmten destination verbunden ist. Endnutzer haben typischerweise mehrere lokale destinations auf ihrem router — zum Beispiel eine, die zu IRC-Servern weiterleitet, eine andere, die den anonymen Webserver des Nutzers (“I2P Site”) unterstützt, eine weitere für eine I2Phex-Instanz, eine für Torrents, usw.

Ein weiteres wichtiges Konzept, das verstanden werden muss, ist der “tunnel”. Ein tunnel ist ein gerichteter Pfad durch eine explizit ausgewählte Liste von Routern. Geschichtete Verschlüsselung wird verwendet, sodass jeder der Router nur eine einzige Schicht entschlüsseln kann. Die entschlüsselten Informationen enthalten die IP des nächsten Routers zusammen mit den verschlüsselten Informationen, die weitergeleitet werden sollen. Jeder tunnel hat einen Startpunkt (den ersten Router, auch als “Gateway” bekannt) und einen Endpunkt. Nachrichten können nur in eine Richtung gesendet werden. Um Nachrichten zurückzusenden, ist ein weiterer tunnel erforderlich.

Abbildung 1: Es gibt zwei Arten von tunnels: inbound und outbound.

Es gibt zwei Arten von tunneln: “Outbound” tunnels senden Nachrichten weg vom tunnel-Ersteller, während “Inbound” tunnels Nachrichten zum tunnel-Ersteller bringen. Durch die Kombination dieser beiden tunnel können Benutzer Nachrichten aneinander senden. Der Absender (“Alice” im obigen Bild) richtet einen outbound tunnel ein, während der Empfänger (“Bob” im obigen Bild) einen inbound tunnel erstellt. Das Gateway eines inbound tunnels kann Nachrichten von jedem anderen Benutzer empfangen und wird sie weiterleiten bis zum Endpunkt (“Bob”). Der Endpunkt des outbound tunnels muss die Nachricht an das Gateway des inbound tunnels weiterleiten. Dazu fügt die Absenderin (“Alice”) Anweisungen zu ihrer verschlüsselten Nachricht hinzu. Sobald der Endpunkt des outbound tunnels die Nachricht entschlüsselt, erhält er Anweisungen, die Nachricht an das korrekte inbound Gateway (das Gateway zu “Bob”) weiterzuleiten.

Ein drittes wichtiges Konzept, das verstanden werden muss, ist I2Ps “network database” (oder “netDb”) — ein Paar von Algorithmen, die zum Teilen von Netzwerk-Metadaten verwendet werden. Die beiden Arten von Metadaten, die übertragen werden, sind “routerInfo” und “leaseSets” — die routerInfo gibt Routern die notwendigen Daten, um einen bestimmten Router zu kontaktieren (ihre öffentlichen Schlüssel, Transport-Adressen, etc.), während das leaseSet Routern die Informationen liefert, die zum Kontaktieren eines bestimmten Ziels erforderlich sind. Ein leaseSet enthält eine Anzahl von “Leases”. Jeder dieser Leases spezifiziert ein Tunnel-Gateway, das es ermöglicht, ein bestimmtes Ziel zu erreichen. Die vollständigen Informationen, die in einem Lease enthalten sind:

Eingangs-Gateway für einen tunnel, der das Erreichen eines bestimmten Ziels ermöglicht.
Zeitpunkt, wann ein tunnel abläuft.
Paar von öffentlichen Schlüsseln, um Nachrichten verschlüsseln zu können (zum Senden durch den tunnel und Erreichen des Ziels).

Router senden ihre routerInfo direkt an die netDb, während leaseSets durch ausgehende tunnel gesendet werden (leaseSets müssen anonym gesendet werden, um eine Korrelation zwischen einem router und seinen leaseSets zu vermeiden).

Wir können die oben genannten Konzepte kombinieren, um erfolgreiche Verbindungen im Netzwerk aufzubauen.

Um ihre eigenen eingehenden und ausgehenden tunnel zu erstellen, führt Alice eine Suche in der netDb durch, um routerInfo zu sammeln. Auf diese Weise sammelt sie Listen von Peers, die sie als Hops in ihren tunneln verwenden kann. Sie kann dann eine Build-Nachricht an den ersten Hop senden, den Aufbau eines tunnels anfordern und diesen router bitten, die Konstruktionsnachricht weiterzuleiten, bis der tunnel aufgebaut wurde.

Informationen zu anderen Routern anfordern

Abbildung 2: Router-Informationen werden verwendet, um tunnel zu erstellen.

Wenn Alice eine Nachricht an Bob senden möchte, führt sie zuerst eine Abfrage in der netDb durch, um Bobs leaseSet zu finden, wodurch sie seine aktuellen eingehenden tunnel-Gateways erhält. Sie wählt dann einen ihrer ausgehenden tunnels aus und sendet die Nachricht mit Anweisungen für den Endpunkt des ausgehenden tunnels, die Nachricht an eines von Bobs eingehenden tunnel-Gateways weiterzuleiten. Wenn der Endpunkt des ausgehenden tunnels diese Anweisungen erhält, leitet er die Nachricht wie angefordert weiter, und wenn Bobs eingehendes tunnel-Gateway sie erhält, wird sie durch den tunnel zu Bobs router weitergeleitet. Wenn Alice möchte, dass Bob auf die Nachricht antworten kann, muss sie ihr eigenes Ziel explizit als Teil der Nachricht selbst übertragen. Dies kann durch die Einführung einer höheren Ebene erreicht werden, was in der streaming Bibliothek gemacht wird. Alice kann auch die Antwortzeit verkürzen, indem sie ihr aktuellstes LeaseSet mit der Nachricht bündelt, sodass Bob keine netDb-Abfrage dafür durchführen muss, wenn er antworten möchte, aber dies ist optional.

Abbildung 3: LeaseSets werden verwendet, um ausgehende und eingehende Tunnels zu verbinden.

Während die tunnel selbst über mehrschichtige Verschlüsselung verfügen, um unbefugte Offenlegung gegenüber Peers innerhalb des Netzwerks zu verhindern (wie es auch die Transportschicht selbst tut, um unbefugte Offenlegung gegenüber Peers außerhalb des Netzwerks zu verhindern), ist es notwendig, eine zusätzliche Ende-zu-Ende-Verschlüsselungsschicht hinzuzufügen, um die Nachricht vor dem Endpunkt des ausgehenden tunnels und dem Gateway des eingehenden tunnels zu verbergen. Diese “garlic encryption ” ermöglicht es Alices router, mehrere Nachrichten in eine einzige “garlic message” zu verpacken, verschlüsselt mit einem bestimmten öffentlichen Schlüssel, sodass zwischengeschaltete Peers weder bestimmen können, wie viele Nachrichten sich in der garlic befinden, was diese Nachrichten besagen, noch wohin diese einzelnen Gewürznelken bestimmt sind. Für die typische Ende-zu-Ende-Kommunikation zwischen Alice und Bob wird die garlic mit dem öffentlichen Schlüssel verschlüsselt, der in Bobs leaseSet veröffentlicht ist, wodurch die Nachricht verschlüsselt werden kann, ohne den öffentlichen Schlüssel an Bobs eigenen router weiterzugeben.

Eine weitere wichtige Tatsache, die man im Hinterkopf behalten sollte, ist, dass I2P vollständig nachrichtenbasiert ist und dass einige Nachrichten unterwegs verloren gehen können. Anwendungen, die I2P verwenden, können die nachrichtenorientierten Schnittstellen nutzen und sich selbst um ihre Staukontrolle und Zuverlässigkeitsanforderungen kümmern, aber die meisten wären am besten bedient, wenn sie die bereitgestellte streaming Bibliothek wiederverwenden, um I2P als streambasiertes Netzwerk zu betrachten.

Tunnels

Sowohl eingehende als auch ausgehende tunnel funktionieren nach ähnlichen Prinzipien. Das tunnel-Gateway sammelt eine Anzahl von tunnel-Nachrichten und verarbeitet sie schließlich zu etwas für die tunnel-Übertragung vor. Als nächstes verschlüsselt das Gateway diese vorverarbeiteten Daten und leitet sie an den ersten Hop weiter. Dieser Peer und die nachfolgenden tunnel-Teilnehmer fügen eine Verschlüsselungsschicht hinzu, nachdem sie überprüft haben, dass es sich nicht um ein Duplikat handelt, bevor sie es an den nächsten Peer weiterleiten. Schließlich kommt die Nachricht am Endpunkt an, wo die Nachrichten wieder aufgeteilt und wie angefordert weitergeleitet werden. Der Unterschied liegt darin, was der tunnel-Ersteller tut — bei eingehenden tunnels ist der Ersteller der Endpunkt und entschlüsselt einfach alle hinzugefügten Schichten, während bei ausgehenden tunnels der Ersteller das Gateway ist und alle Schichten vorab entschlüsselt, sodass nach dem Hinzufügen aller Schichten der Pro-Hop-Verschlüsselung die Nachricht im Klartext am tunnel-Endpunkt ankommt.

Die Wahl der spezifischen Peers zur Weiterleitung von Nachrichten sowie deren besondere Reihenfolge ist wichtig für das Verständnis sowohl der Anonymitäts- als auch der Leistungsmerkmale von I2P. Während die network database (unten) ihre eigenen Kriterien für die Auswahl der zu befragenden Peers und die Speicherung von Einträgen hat, können tunnel-Ersteller beliebige Peers im Netzwerk in beliebiger Reihenfolge (und sogar beliebig oft) in einem einzigen tunnel verwenden. Wenn perfekte Latenz- und Kapazitätsdaten global bekannt wären, würde die Auswahl und Reihenfolge von den spezifischen Bedürfnissen des Clients in Verbindung mit seinem Bedrohungsmodell bestimmt werden. Leider sind Latenz- und Kapazitätsdaten nicht trivial anonym zu sammeln, und die Abhängigkeit von nicht vertrauenswürdigen Peers für die Bereitstellung dieser Informationen hat ihre eigenen schwerwiegenden Anonymitätsauswirkungen.

Aus Anonymitätssicht wäre die einfachste Technik, peers zufällig aus dem gesamten Netzwerk auszuwählen, sie zufällig zu ordnen und diese peers in dieser Reihenfolge für alle Ewigkeit zu verwenden. Aus Leistungssicht wäre die einfachste Technik, die schnellsten peers mit der notwendigen freien Kapazität auszuwählen, die Last auf verschiedene peers zu verteilen, um transparentes Failover zu handhaben, und den tunnel jedes Mal neu aufzubauen, wenn sich Kapazitätsinformationen ändern. Während ersteres sowohl brüchig als auch ineffizient ist, erfordert letzteres unzugängliche Informationen und bietet unzureichende Anonymität. I2P arbeitet stattdessen daran, eine Reihe von peer-Auswahlstrategien anzubieten, gekoppelt mit anonymitätsbewusstem Messcode, um die peers nach ihren Profilen zu organisieren.

Als Grundlage erstellt I2P kontinuierlich Profile der Peers, mit denen es interagiert, indem es ihr indirektes Verhalten misst — zum Beispiel wird, wenn ein Peer auf eine netDb-Abfrage in 1,3 Sekunden antwortet, diese Roundtrip-Latenz in den Profilen aller router aufgezeichnet, die an den beiden tunnels (eingehend und ausgehend) beteiligt sind, durch die Anfrage und Antwort gelaufen sind, sowie im Profil des abgefragten Peers. Direkte Messungen wie Latenz oder Überlastung der Transportschicht werden nicht als Teil des Profils verwendet, da sie manipuliert und mit dem messenden router in Verbindung gebracht werden können, wodurch dieser trivialen Angriffen ausgesetzt wird. Während diese Profile gesammelt werden, wird eine Reihe von Berechnungen für jedes durchgeführt, um seine Leistung zusammenzufassen — seine Latenz, Kapazität zur Bewältigung vieler Aktivitäten, ob sie derzeit überlastet sind und wie gut sie in das Netzwerk integriert zu sein scheinen. Diese Berechnungen werden dann für aktive Peers verglichen, um die router in vier Stufen zu organisieren — schnell und hohe Kapazität, hohe Kapazität, nicht ausfallend und ausfallend. Die Schwellenwerte für diese Stufen werden dynamisch bestimmt, und obwohl sie derzeit relativ einfache Algorithmen verwenden, existieren Alternativen.

Mit diesen Profildaten ist die einfachste vernünftige Peer-Auswahlstrategie, Peers zufällig aus der obersten Stufe (schnell und hohe Kapazität) auszuwählen, und dies wird derzeit für Client-tunnel eingesetzt. Exploratory tunnels (verwendet für netDb und tunnel-Verwaltung) wählen Peers zufällig aus der Stufe “nicht fehlschlagend” aus (die auch router in ‘besseren’ Stufen einschließt), was es dem Peer ermöglicht, router breiter zu sampeln und dabei die Peer-Auswahl durch randomisiertes Hill climbing zu optimieren. Diese Strategien allein geben jedoch Informationen über die Peers in der obersten Stufe des routers durch Vorgänger- und netDb-Harvesting-Angriffe preis. Es existieren mehrere Alternativen, die, obwohl sie die Last nicht so gleichmäßig verteilen, die von bestimmten Klassen von Angreifern durchgeführten Attacken adressieren.

Durch die Auswahl eines zufälligen Schlüssels und die Anordnung der Peers entsprechend ihrer XOR-Distanz zu diesem wird die preisgegeben Information bei Predecessor- und Harvesting-Angriffen entsprechend der Ausfallrate der Peers und der Fluktuation der Ebene reduziert. Eine weitere einfache Strategie für den Umgang mit netDb-Harvesting-Angriffen besteht darin, einfach die eingehenden tunnel-Gateways zu fixieren, aber die Peers weiter hinten in den tunnels zu randomisieren. Um bei Predecessor-Angriffen für Adversare, die der Client kontaktiert, zu verfahren, würden auch die Endpunkte der ausgehenden tunnel fixiert bleiben. Die Auswahl, welcher Peer am exponiertesten Punkt zu fixieren ist, müsste natürlich eine Begrenzung der Dauer haben, da alle Peers schließlich ausfallen, so dass es entweder reaktiv angepasst oder proaktiv vermieden werden könnte, um eine gemessene mittlere Zeit zwischen Ausfällen anderer router nachzuahmen. Diese beiden Strategien können wiederum kombiniert werden, indem ein fixierter exponierter Peer und eine XOR-basierte Anordnung innerhalb der tunnel selbst verwendet werden. Eine rigidere Strategie würde die exakten Peers und die Anordnung eines potentiellen tunnel fixieren und nur einzelne Peers verwenden, wenn alle von ihnen zustimmen, jedes Mal auf die gleiche Weise zu partizipieren. Dies unterscheidet sich von der XOR-basierten Anordnung dadurch, dass der Predecessor und Successor jedes Peers immer derselbe ist, während die XOR-Methode nur sicherstellt, dass sich ihre Reihenfolge nicht ändert.

Wie bereits erwähnt, enthält I2P derzeit (Version 0.8) die oben beschriebene gestufte Zufallsstrategie mit XOR-basierter Sortierung. Eine detailliertere Diskussion der Mechanismen, die beim tunnel-Betrieb, -Management und der Peer-Auswahl beteiligt sind, finden Sie in der tunnel-Spezifikation .

Netzwerkdatenbank (netDb)

Wie bereits erwähnt, funktioniert I2Ps netDb zur Verteilung der Netzwerk-Metadaten. Dies wird auf der Seite network database detailliert beschrieben, aber eine grundlegende Erklärung ist unten verfügbar.

Alle I2P router enthalten eine lokale netDb, aber nicht alle router nehmen am DHT teil oder antworten auf leaseSet-Anfragen. Die router, die am DHT teilnehmen und auf leaseSet-Anfragen antworten, werden ‘floodfills’ genannt. Router können manuell als floodfills konfiguriert werden oder werden automatisch zu floodfills, wenn sie genügend Kapazität haben und andere Kriterien für zuverlässigen Betrieb erfüllen.

Andere I2P router speichern ihre Daten und suchen nach Daten, indem sie einfache ‘store’- und ’lookup’-Abfragen an die floodfills senden. Wenn ein floodfill router eine ‘store’-Abfrage erhält, verbreitet er die Informationen an andere floodfill router unter Verwendung des Kademlia-Algorithmus . Die ’lookup’-Abfragen funktionieren derzeit anders, um ein wichtiges Sicherheitsproblem zu vermeiden. Wenn eine Suche durchgeführt wird, leitet der floodfill router die Suchanfrage nicht an andere Peers weiter, sondern antwortet immer selbst (wenn er die angeforderten Daten hat).

Zwei Arten von Informationen werden in der Netzwerkdatenbank gespeichert.

Eine RouterInfo speichert Informationen über einen bestimmten I2P router und wie man ihn kontaktiert
Ein leaseSet speichert Informationen über ein bestimmtes Ziel (z.B. I2P Website, E-Mail-Server…)

All diese Informationen werden von der veröffentlichenden Partei signiert und von jedem I2P router, der die Informationen verwendet oder speichert, verifiziert. Zusätzlich enthalten die Daten Zeitinformationen, um die Speicherung alter Einträge und mögliche Angriffe zu vermeiden. Dies ist auch der Grund, warum I2P den notwendigen Code für die Aufrechterhaltung der korrekten Zeit mitliefert, gelegentlich einige SNTP-Server abfragt (standardmäßig das pool.ntp.org Round Robin) und Zeitabweichungen zwischen routern auf der Transportschicht erkennt.

Einige zusätzliche Anmerkungen sind ebenfalls wichtig.

Unveröffentlichte und verschlüsselte leaseSets: Man möchte möglicherweise, dass nur bestimmte Personen ein Ziel erreichen können. Dies ist möglich, indem man das Ziel nicht in der netDb veröffentlicht. Sie müssen das Ziel jedoch auf andere Weise übertragen. Dies wird durch ‘verschlüsselte leaseSets’ unterstützt. Diese leaseSets können nur von Personen mit Zugang zum Entschlüsselungsschlüssel dekodiert werden.
Bootstrapping: Das Bootstrapping der netDb ist ziemlich einfach. Sobald ein router es schafft, eine einzige routerInfo eines erreichbaren Peers zu erhalten, kann er diesen router nach Verweisen auf andere router im Netzwerk abfragen. Derzeit veröffentlichen mehrere Benutzer ihre routerInfo-Dateien auf einer Website, um diese Informationen verfügbar zu machen. I2P verbindet sich automatisch mit einer dieser Websites, um routerInfo-Dateien zu sammeln und das Bootstrapping durchzuführen. I2P nennt diesen Bootstrap-Prozess “Reseeding”.
Lookup-Skalierbarkeit: Lookups im I2P-Netzwerk sind iterativ, nicht rekursiv. Wenn ein Lookup von einem floodfill fehlschlägt, wird der Lookup zum nächstgelegenen floodfill wiederholt. Der floodfill fragt nicht rekursiv einen anderen floodfill nach den Daten. Iterative Lookups sind skalierbar für große DHT-Netzwerke.

Transportprotokolle

Die Kommunikation zwischen Routern muss Vertraulichkeit und Integrität gegen externe Angreifer gewährleisten und gleichzeitig authentifizieren, dass der kontaktierte Router derjenige ist, der eine bestimmte Nachricht erhalten sollte. Die Einzelheiten, wie Router mit anderen Routern kommunizieren, sind nicht kritisch — drei verschiedene Protokolle wurden zu unterschiedlichen Zeitpunkten verwendet, um diese grundlegenden Anforderungen zu erfüllen.

I2P unterstützt derzeit zwei Transportprotokolle, NTCP2 über TCP und SSU2 über UDP. Diese haben die vorherigen Versionen der Protokolle, NTCP und SSU , ersetzt, die nun veraltet sind. Beide Protokolle unterstützen sowohl IPv4 als auch IPv6. Durch die Unterstützung sowohl von TCP- als auch UDP-Transporten kann I2P effektiv die meisten Firewalls durchdringen, einschließlich derjenigen, die dazu bestimmt sind, Datenverkehr in restriktiven Zensurregimen zu blockieren. NTCP2 und SSU2 wurden entwickelt, um moderne Verschlüsselungsstandards zu verwenden, die Widerstandsfähigkeit gegen Verkehrsidentifikation zu verbessern, Effizienz und Sicherheit zu erhöhen und NAT-Durchquerung robuster zu machen. router veröffentlichen jeden unterstützten Transport und jede IP-Adresse in der netDb. router mit Zugang zu öffentlichen IPv4- und IPv6-Netzwerken werden normalerweise vier Adressen veröffentlichen, eine für jede Kombination von NTCP2/SSU2 mit IPv4/IPv6.

SSU2 unterstützt und erweitert die Ziele von SSU. SSU2 weist viele Ähnlichkeiten zu anderen modernen UDP-basierten Protokollen wie Wireguard und QUIC auf. Zusätzlich zum zuverlässigen Transport von Netzwerknachrichten über UDP bietet SSU2 spezialisierte Funktionen für Peer-to-Peer, kooperative IP-Adresserkennung, Firewall-Erkennung und NAT-Durchquerung. Wie in der SSU-Spezifikation beschrieben:

Das Ziel dieses Protokolls ist es, sichere, authentifizierte, halbzuverlässige und ungeordnete Nachrichtenübertragung bereitzustellen, wobei nur eine minimale Menge von Daten preisgegeben wird, die für Dritte leicht erkennbar sind. Es sollte hochgradige Kommunikation sowie TCP-freundliche Staukontrolle unterstützen und kann PMTU-Erkennung einschließen. Es sollte in der Lage sein, Massendaten effizient mit Raten zu übertragen, die für Heimanwender ausreichend sind. Darüber hinaus sollte es Techniken zur Bewältigung von Netzwerkhindernissen wie den meisten NATs oder Firewalls unterstützen.

NTCP2 unterstützt und erweitert die Ziele von NTCP. Es bietet eine effiziente und vollständig verschlüsselte Übertragung von Netzwerknachrichten über TCP sowie Widerstand gegen Verkehrsidentifikation unter Verwendung moderner Verschlüsselungsstandards.

I2P unterstützt mehrere Transporte gleichzeitig. Ein bestimmter Transport für eine ausgehende Verbindung wird mit “Geboten” ausgewählt. Jeder Transport bietet für die Verbindung und der relative Wert dieser Gebote bestimmt die Priorität. Transporte können mit unterschiedlichen Geboten antworten, je nachdem, ob bereits eine etablierte Verbindung zu dem Peer besteht.

Die Bid-Werte (Priorität) sind implementierungsabhängig und können je nach Verkehrsbedingungen, Verbindungsanzahl und anderen Faktoren variieren. Router veröffentlichen auch ihre Transportpräferenzen für eingehende Verbindungen in der netDb als Transport-“Kosten” für jeden Transport und jede Adresse.

Kryptographie

I2P verwendet Kryptographie auf mehreren Protokollebenen für Verschlüsselung, Authentifizierung und Verifikation. Die wichtigsten Protokollebenen sind: Transporte, tunnel build messages, tunnel layer encryption, network database messages und End-zu-End (garlic) messages. I2Ps ursprüngliches Design verwendete einen kleinen Satz kryptographischer Primitive, die zu dieser Zeit als sicher galten. Dazu gehörten ElGamal asymmetrische Verschlüsselung, DSA-SHA1 Signaturen, AES256/CBC symmetrische Verschlüsselung und SHA-256 Hashes. Da die verfügbare Rechenleistung zunahm und sich die kryptographische Forschung über die Jahre erheblich weiterentwickelte, musste I2P seine Primitive und Protokolle aktualisieren. Daher fügten wir ein Konzept von “Verschlüsselungstypen” und “Signaturtypen” hinzu und erweiterten unsere Protokolle um diese Kennungen und Unterstützungsanzeigen. Dies ermöglicht es uns, die Netzwerkunterstützung für moderne Kryptographie regelmäßig zu aktualisieren und zu erweitern und das Netzwerk für neue Primitive zukunftssicher zu machen, ohne die Rückwärtskompatibilität zu brechen oder einen “Stichtag” für Netzwerk-Updates zu erfordern. Einige Signatur- und Verschlüsselungstypen sind auch für experimentelle Nutzung reserviert.

Die aktuell in den meisten Protokollschichten verwendeten Primitive sind X25519-Schlüsselaustausch, EdDSA-Signaturen, ChaCha20/Poly1305 authentifizierte symmetrische Verschlüsselung und SHA-256-Hashes. AES256 wird weiterhin für die tunnel-Schicht-Verschlüsselung verwendet. Diese modernen Protokolle werden für den Großteil der Netzwerkkommunikation eingesetzt. Ältere Primitive wie ElGamal, ECDSA und DSA-SHA1 werden weiterhin von den meisten Implementierungen für Rückwärtskompatibilität bei der Kommunikation mit älteren routern unterstützt. Einige alte Protokolle wurden als veraltet markiert und/oder vollständig entfernt. In naher Zukunft werden wir mit der Forschung zu einer Migration auf Post-Quantum (PQ) oder Hybrid-PQ-Verschlüsselung und -Signaturen beginnen, um unsere robusten Sicherheitsstandards aufrechtzuerhalten.

Diese kryptographischen Grundbausteine werden kombiniert, um I2Ps mehrstufige Verteidigung gegen verschiedene Angreifer zu bieten. Auf der untersten Ebene wird die Kommunikation zwischen Routern durch die Transportschicht-Sicherheit geschützt. Tunnel -Nachrichten, die über die Transporte übertragen werden, haben ihre eigene mehrstufige Verschlüsselung. Verschiedene andere Nachrichten werden innerhalb von “garlic messages” übertragen, die ebenfalls verschlüsselt sind.

Garlic Messages

Garlic messages sind eine Erweiterung der “Zwiebel”-geschichteten Verschlüsselung, die es ermöglicht, dass der Inhalt einer einzelnen Nachricht mehrere “Gewürznelken” enthält — vollständig geformte Nachrichten zusammen mit ihren eigenen Zustellungsanweisungen. Nachrichten werden in eine garlic message eingewickelt, wann immer die Nachricht andernfalls im Klartext durch einen Peer gehen würde, der keinen Zugang zu den Informationen haben sollte — zum Beispiel, wenn ein router einen anderen router bitten möchte, an einem tunnel teilzunehmen, verpacken sie die Anfrage in ein garlic, verschlüsseln dieses garlic mit dem öffentlichen Schlüssel des empfangenden routers und leiten es durch einen tunnel weiter. Ein weiteres Beispiel ist, wenn ein Client eine Nachricht an ein Ziel senden möchte — der router des Senders wird diese Datennachricht (zusammen mit einigen anderen Nachrichten) in ein garlic einwickeln, dieses garlic mit dem öffentlichen Schlüssel verschlüsseln, der im leaseSet des Empfängers veröffentlicht ist, und es durch die entsprechenden tunnel weiterleiten.

Die “Anweisungen”, die an jede Zwiebel innerhalb der Verschlüsselungsschicht angehängt sind, beinhalten die Möglichkeit zu verlangen, dass die Zwiebel lokal, an einen entfernten router oder an einen entfernten tunnel auf einem entfernten router weitergeleitet wird. Es gibt Felder in diesen Anweisungen, die es einem Peer ermöglichen zu verlangen, dass die Zustellung verzögert wird, bis eine bestimmte Zeit oder Bedingung erfüllt ist, obwohl diese erst berücksichtigt werden, wenn die nichttrivialen Verzögerungen eingesetzt werden. Es ist möglich, garlic-Nachrichten explizit über eine beliebige Anzahl von Hops zu routen, ohne tunnels zu erstellen, oder sogar tunnel-Nachrichten umzuleiten, indem man sie in garlic-Nachrichten einpackt und sie über eine Anzahl von Hops weiterleitet, bevor sie an den nächsten Hop im tunnel zugestellt werden, aber diese Techniken werden in der aktuellen Implementierung derzeit nicht verwendet.

Session Tags

Als unzuverlässiges, ungeordnetes, nachrichtenbasiertes System verwendet I2P eine einfache Kombination aus asymmetrischen und symmetrischen Verschlüsselungsalgorithmen, um Datenvertraulichkeit und -integrität für garlic messages zu gewährleisten. Die ursprüngliche Kombination wurde als ElGamal/AES+SessionTags bezeichnet, aber das ist eine übermäßig ausführliche Art, die einfache Verwendung von 2048bit ElGamal, AES256, SHA256 und 32-Byte-Nonces zu beschreiben. Während dieses Protokoll immer noch unterstützt wird, ist der größte Teil des Netzwerks zu einem neuen Protokoll migriert: ECIES-X25519-AEAD-Ratchet. Dieses Protokoll kombiniert X25519, ChaCha20/Poly1305 und einen synchronisierten PRNG zur Generierung der 32-Byte-Nonces. Beide Protokolle werden im Folgenden kurz beschrieben.

ElGamal/AES+SessionTags

Wenn ein router zum ersten Mal eine garlic-Nachricht an einen anderen router verschlüsseln möchte, verschlüsselt er das Schlüsselmaterial für einen AES256-Sitzungsschlüssel mit ElGamal und hängt die AES256/CBC-verschlüsselte Nutzlast nach diesem verschlüsselten ElGamal-Block an. Zusätzlich zur verschlüsselten Nutzlast enthält der AES-verschlüsselte Bereich die Länge der Nutzlast, den SHA256-Hash der unverschlüsselten Nutzlast sowie eine Anzahl von “session tags” — zufällige 32-Byte-Nonces. Wenn der Sender das nächste Mal eine garlic-Nachricht an einen anderen router verschlüsseln möchte, verschlüsselt er nicht erneut einen neuen Sitzungsschlüssel mit ElGamal, sondern wählt einfach einen der zuvor übertragenen session tags aus und AES-verschlüsselt die Nutzlast wie zuvor, unter Verwendung des Sitzungsschlüssels, der mit diesem session tag verwendet wurde, dem der session tag selbst vorangestellt wird. Wenn ein router eine garlic-verschlüsselte Nachricht erhält, überprüft er die ersten 32 Bytes, um zu sehen, ob sie mit einem verfügbaren session tag übereinstimmen — falls ja, entschlüsselt er die Nachricht einfach mit AES, falls nicht, entschlüsselt er den ersten Block mit ElGamal.

Jeder Session-Tag kann nur einmal verwendet werden, um zu verhindern, dass interne Gegner unnötigerweise verschiedene Nachrichten als zwischen denselben Routern stammend korrelieren. Der Sender einer ElGamal/AES+SessionTag verschlüsselten Nachricht wählt, wann und wie viele Tags übertragen werden sollen, und versorgt den Empfänger im Voraus mit genügend Tags, um eine Serie von Nachrichten abzudecken. Garlic-Nachrichten können die erfolgreiche Tag-Übertragung erkennen, indem sie eine kleine zusätzliche Nachricht als Clove (eine “Delivery Status Message”) bündeln — wenn die Garlic-Nachricht beim beabsichtigten Empfänger ankommt und erfolgreich entschlüsselt wird, ist diese kleine Delivery Status Message eine der freigesetzten Cloves und enthält Anweisungen für den Empfänger, die Clove an den ursprünglichen Sender zurückzusenden (natürlich durch einen inbound Tunnel). Wenn der ursprüngliche Sender diese Delivery Status Message erhält, weiß er, dass die in der Garlic-Nachricht gebündelten Session-Tags erfolgreich übertragen wurden.

Session Tags selbst haben eine sehr kurze Lebensdauer, nach der sie verworfen werden, wenn sie nicht verwendet werden. Zusätzlich ist die für jeden Schlüssel gespeicherte Menge begrenzt, ebenso wie die Anzahl der Schlüssel selbst — wenn zu viele ankommen, können entweder neue oder alte Nachrichten verworfen werden. Der Sender verfolgt, ob Nachrichten mit Session Tags durchkommen, und wenn nicht ausreichend kommuniziert wird, kann er diejenigen verwerfen, die zuvor als ordnungsgemäß zugestellt angenommen wurden, und zur vollständigen teuren ElGamal-Verschlüsselung zurückkehren.

ECIES-X25519-AEAD-Ratchet

ElGamal/AES+SessionTags erforderte erheblichen Mehraufwand in verschiedener Hinsicht. Die CPU-Nutzung war hoch, da ElGamal sehr langsam ist. Die Bandbreite war übermäßig beansprucht, weil große Mengen an Session-Tags im Voraus übertragen werden mussten und weil ElGamal-Public-Keys sehr groß sind. Der Speicherverbrauch war hoch aufgrund der Anforderung, große Mengen an Session-Tags zu speichern. Die Zuverlässigkeit wurde durch verlorene Session-Tag-Übertragungen beeinträchtigt.

ECIES-X25519-AEAD-Ratchet wurde entwickelt, um diese Probleme zu lösen. X25519 wird für den Schlüsselaustausch verwendet. ChaCha20/Poly1305 wird für die authentifizierte symmetrische Verschlüsselung verwendet. Verschlüsselungsschlüssel werden “doppelt geratchet” oder periodisch rotiert. Session Tags werden von 32 Bytes auf 8 Bytes reduziert und mit einem PRNG generiert. Das Protokoll weist viele Ähnlichkeiten mit dem Signal-Protokoll auf, das in Signal und WhatsApp verwendet wird. Dieses Protokoll bietet erheblich geringeren Overhead bei CPU, RAM und Bandbreite.

Die Session-Tags werden von einem deterministischen synchronisierten PRNG generiert, der an beiden Enden der Session läuft, um Session-Tags und Session-Schlüssel zu erzeugen. Der PRNG ist ein HKDF mit einem SHA-256 HMAC und wird aus dem X25519 DH-Ergebnis gespeist. Session-Tags werden niemals im Voraus übertragen; sie werden nur zusammen mit der Nachricht eingeschlossen. Der Empfänger speichert eine begrenzte Anzahl von Session-Schlüsseln, indexiert nach Session-Tag. Der Sender muss keine Session-Tags oder Schlüssel speichern, da sie nicht im Voraus gesendet werden; sie können bei Bedarf generiert werden. Indem dieser PRNG zwischen Sender und Empfänger ungefähr synchronisiert gehalten wird (der Empfänger berechnet ein Fenster der nächsten z.B. 50 Tags im Voraus), wird der Aufwand für das periodische Bündeln einer großen Anzahl von Tags eliminiert.

Zukunft

I2Ps Protokolle sind auf den meisten Plattformen effizient, einschließlich Mobiltelefonen, und sicher für die meisten Bedrohungsmodelle. Es gibt jedoch mehrere Bereiche, die weitere Verbesserungen erfordern, um den Bedürfnissen derjenigen gerecht zu werden, die mächtigen staatlich geförderten Gegnern gegenüberstehen, und um den Bedrohungen durch kontinuierliche kryptographische Fortschritte und ständig zunehmende Rechenleistung zu begegnen. Zwei mögliche Funktionen, restricted routes und variable latency, wurden 2003 von jrandom vorgeschlagen. Obwohl wir nicht mehr planen, diese Funktionen zu implementieren, werden sie im Folgenden beschrieben.

Eingeschränkter Routenbetrieb

I2P ist ein Overlay-Netzwerk, das darauf ausgelegt ist, auf einem funktionierenden paketvermittelten Netzwerk zu laufen und das End-to-End-Prinzip zu nutzen, um Anonymität und Sicherheit zu bieten. Während das Internet das End-to-End-Prinzip nicht mehr vollständig umsetzt (aufgrund der Verwendung von NAT), benötigt I2P dennoch, dass ein wesentlicher Teil des Netzwerks erreichbar ist — es kann eine Anzahl von Peers an den Rändern geben, die mit eingeschränkten Routen laufen, aber I2P enthält keinen geeigneten Routing-Algorithmus für den degenerierten Fall, wo die meisten Peers nicht erreichbar sind. Es würde jedoch auf einem Netzwerk funktionieren, das einen solchen Algorithmus verwendet.

Der eingeschränkte Routenbetrieb, bei dem Grenzen bestehen, welche Peers direkt erreichbar sind, hat verschiedene funktionale und Anonymitätsauswirkungen, die davon abhängen, wie die eingeschränkten Routen behandelt werden. Auf der grundlegendsten Ebene existieren eingeschränkte Routen, wenn sich ein Peer hinter einer NAT oder Firewall befindet, die keine eingehenden Verbindungen zulässt. Dies wurde größtenteils durch die Integration von verteiltem Hole Punching in die Transportschicht behoben, wodurch Personen hinter den meisten NATs und Firewalls unaufgeforderte Verbindungen ohne jede Konfiguration empfangen können. Dies beschränkt jedoch nicht die Preisgabe der IP-Adresse des Peers an router innerhalb des Netzwerks, da sie einfach über den veröffentlichten Introducer mit dem Peer bekannt gemacht werden können.

Über die funktionale Behandlung von eingeschränkten Routen hinaus gibt es zwei Ebenen eingeschränkter Operationen, die verwendet werden können, um die Preisgabe der eigenen IP-Adresse zu begrenzen — die Verwendung router-spezifischer tunnel für die Kommunikation und das Anbieten von ‘Client-Routern’. Für ersteres können router entweder einen neuen Pool von tunneln erstellen oder ihren Erkundungspool wiederverwenden, indem sie die eingehenden Gateways zu einigen von ihnen als Teil ihrer routerInfo anstelle ihrer Transportadressen veröffentlichen. Wenn ein Peer mit ihnen in Kontakt treten möchte, sieht er diese tunnel-Gateways in der netDb und sendet einfach die entsprechende Nachricht über einen der veröffentlichten tunnel an sie. Wenn der Peer hinter der eingeschränkten Route antworten möchte, kann er dies entweder direkt tun (wenn er bereit ist, seine IP dem Peer preiszugeben) oder indirekt über seine ausgehenden tunnel. Wenn die router, zu denen der Peer direkte Verbindungen hat, ihn erreichen wollen (um tunnel-Nachrichten weiterzuleiten, zum Beispiel), priorisieren sie einfach ihre direkte Verbindung über das veröffentlichte tunnel-Gateway. Das Konzept der ‘Client-router’ erweitert einfach die eingeschränkte Route, indem keine router-Adressen veröffentlicht werden. Ein solcher router müsste nicht einmal seine routerInfo in der netDb veröffentlichen, sondern lediglich seine selbst signierte routerInfo den Peers bereitstellen, die er kontaktiert (notwendig, um die öffentlichen Schlüssel des routers zu übertragen).

Es gibt Kompromisse für diejenigen hinter eingeschränkten Routen, da sie wahrscheinlich seltener an den tunneln anderer Personen teilnehmen würden, und die router, mit denen sie verbunden sind, wären in der Lage, Verkehrsmuster zu erkennen, die andernfalls nicht preisgegeben würden. Andererseits könnte es sich lohnen, wenn die Kosten dieser Preisgabe geringer sind als die Kosten für die Bereitstellung einer IP. Dies setzt natürlich voraus, dass die Peers, die der router hinter einer eingeschränkten Route kontaktiert, nicht feindlich gesinnt sind — entweder das Netzwerk ist groß genug, dass die Wahrscheinlichkeit, einen feindlichen Peer für die Verbindung zu verwenden, gering genug ist, oder es werden stattdessen vertrauenswürdige (und möglicherweise temporäre) Peers verwendet.

Restricted routes sind komplex, und das übergeordnete Ziel wurde weitgehend aufgegeben. Mehrere verwandte Verbesserungen haben den Bedarf dafür stark reduziert. Wir unterstützen jetzt UPnP zur automatischen Öffnung von Firewall-Ports. Wir unterstützen sowohl IPv4 als auch IPv6. SSU2 verbesserte die Adresserkennung, Firewall-Zustandsbestimmung und kooperatives NAT hole punching. SSU2, NTCP2 und Adresskompatibilitätsprüfungen stellen sicher, dass tunnel-Hops eine Verbindung herstellen können, bevor der tunnel aufgebaut wird. GeoIP und Länderidentifikation ermöglichen es uns, Peers in Ländern mit restriktiven Firewalls zu vermeiden. Die Unterstützung für “versteckte” router hinter diesen Firewalls hat sich verbessert. Einige Implementierungen unterstützen auch Verbindungen zu Peers in Overlay-Netzwerken wie Yggdrasil.

Variable Latenz

Obwohl sich I2Ps anfängliche Bemühungen hauptsächlich auf die Kommunikation mit geringer Latenz konzentrierten, wurde es von Anfang an mit variablen Latenz-Diensten im Hinterkopf entwickelt. Auf grundlegendster Ebene können Anwendungen, die auf I2P laufen, die Anonymität von mittlerer und hoher Latenz-Kommunikation bieten, während sie ihre Verkehrsmuster trotzdem mit dem Verkehr geringer Latenz vermischen. Intern kann I2P jedoch seine eigene mittlere und hohe Latenz-Kommunikation durch garlic encryption anbieten — dabei wird spezifiziert, dass die Nachricht nach einer bestimmten Verzögerung, zu einer bestimmten Zeit, nach einer bestimmten Anzahl von übertragenen Nachrichten oder einer anderen Mix-Strategie gesendet werden soll. Mit der geschichteten Verschlüsselung würde nur der router wissen, dass die Nachricht hohe Latenz erfordert, bei dem die Nelke die Verzögerungsanfrage preisgegeben hat, wodurch sich der Verkehr noch weiter mit dem Verkehr geringer Latenz vermischen kann. Sobald die Übertragungsvoraussetzung erfüllt ist, leitet der router, der die Nelke festhält (die selbst wahrscheinlich eine garlic-Nachricht wäre), sie einfach wie angefordert weiter — an einen router, an einen tunnel oder höchstwahrscheinlich an ein entferntes Client-Ziel.

Das Ziel von variablen Latenzzeiten-Diensten erfordert erhebliche Ressourcen für Store-and-Forward-Mechanismen, um sie zu unterstützen. Diese Mechanismen können und werden in verschiedenen Messaging-Anwendungen unterstützt, wie z.B. i2p-bote. Auf Netzwerkebene bieten alternative Netzwerke wie Freenet diese Dienste. Wir haben uns entschieden, dieses Ziel auf der I2P router-Ebene nicht zu verfolgen.

Anhang A: Anwendungsschicht

I2P selbst macht nicht wirklich viel — es sendet einfach Nachrichten an entfernte Ziele und empfängt Nachrichten, die an lokale Ziele gerichtet sind — die meiste interessante Arbeit findet in den darüber liegenden Schichten statt. Für sich genommen könnte I2P als anonyme und sichere IP-Schicht betrachtet werden, und die mitgelieferte streaming library als Implementierung einer anonymen und sicheren TCP-Schicht darüber. Darüber hinaus bietet I2PTunnel ein generisches TCP-Proxy-System, um entweder in das I2P-Netzwerk hinein oder aus ihm heraus zu gelangen, plus eine Vielzahl von Netzwerkanwendungen, die weitere Funktionalität für Endbenutzer bereitstellen.

Streaming-Bibliothek

Die I2P-Streaming-Bibliothek kann als generische Streaming-Schnittstelle betrachtet werden (die TCP-Sockets nachahmt), und die Implementierung unterstützt ein Sliding Window Protocol mit mehreren Optimierungen, um die hohe Latenz über I2P zu berücksichtigen. Einzelne Streams können die maximale Paketgröße und andere Optionen anpassen, obwohl die Standardeinstellung von 4KB komprimiert einen vernünftigen Kompromiss zwischen den Bandbreitenkosten der Neuübertragung verlorener Nachrichten und der Latenz mehrerer Nachrichten zu sein scheint.

Darüber hinaus wurde das Protokoll der Streaming-Bibliothek für die Planung und Übermittlung von Nachrichten in Anbetracht der relativ hohen Kosten nachfolgender Nachrichten optimiert, um zu ermöglichen, dass einzelne übertragene Nachrichten so viele verfügbare Informationen wie möglich enthalten. Beispielsweise kann eine kleine HTTP-Transaktion, die über die Streaming-Bibliothek geleitet wird, in einem einzigen Roundtrip abgeschlossen werden — die erste Nachricht bündelt SYN, FIN und die kleine Nutzlast (eine HTTP-Anfrage passt typischerweise hinein) und die Antwort bündelt SYN, FIN, ACK und die kleine Nutzlast (viele HTTP-Antworten passen hinein). Obwohl eine zusätzliche ACK übertragen werden muss, um dem HTTP-Server mitzuteilen, dass das SYN/FIN/ACK empfangen wurde, kann der lokale HTTP-Proxy die vollständige Antwort sofort an den Browser weiterleiten.

Im Großen und Ganzen ähnelt die Streaming-Bibliothek jedoch stark einer Abstraktion von TCP, mit ihren Sliding Windows, Congestion-Control-Algorithmen (sowohl Slow Start als auch Congestion Avoidance) und dem allgemeinen Paketverhalten (ACK, SYN, FIN, RST, etc.).

Naming Library und Adressbuch

Für weitere Informationen siehe die Seite Naming and Address Book .

Entwickelt von: mihi, Ragnarok

Die Namensgebung innerhalb von I2P war seit den Anfängen ein oft diskutiertes Thema mit Befürwortern aus dem gesamten Spektrum der Möglichkeiten. Angesichts der inhärenten Anforderung von I2P an sichere Kommunikation und dezentrale Funktionsweise scheidet jedoch das traditionelle DNS-artige Namenssystem klar aus, ebenso wie Abstimmungssysteme nach dem Prinzip “die Mehrheit entscheidet”. Stattdessen wird I2P mit einer generischen Namensbibliothek und einer Basisimplementierung ausgeliefert, die darauf ausgelegt ist, mit einer lokalen Name-zu-destination-Zuordnung zu arbeiten, sowie einer optionalen Zusatzanwendung namens “Address Book”. Das Address Book ist ein web-of-trust-getriebenes sicheres, verteiltes und menschenlesbares Namenssystem, das nur die Forderung nach globaler Eindeutigkeit aller menschenlesbaren Namen opfert, indem es nur lokale Eindeutigkeit vorschreibt. Während alle Nachrichten in I2P kryptographisch durch ihre destination adressiert werden, können verschiedene Personen lokale Address Book-Einträge für “Alice” haben, die sich auf unterschiedliche destinations beziehen. Menschen können immer noch neue Namen entdecken, indem sie veröffentlichte Address Books von Peers importieren, die in ihrem web of trust spezifiziert sind, indem sie Einträge hinzufügen, die durch Dritte bereitgestellt werden, oder (falls einige Personen eine Reihe von veröffentlichten Address Books mit einem “Wer zuerst kommt, mahlt zuerst”-Registrierungssystem organisieren) können Menschen wählen, diese Address Books als Nameserver zu behandeln und damit traditionelles DNS zu emulieren.

I2P fördert jedoch nicht die Nutzung von DNS-ähnlichen Diensten, da der Schaden durch das Kapern einer Website enorm sein kann – und unsichere destinations haben keinen Wert. DNSsec selbst fällt immer noch auf Registrare und Zertifizierungsstellen zurück, während bei I2P Anfragen, die an eine destination gesendet werden, nicht abgefangen oder die Antwort gefälscht werden können, da sie mit den öffentlichen Schlüsseln der destination verschlüsselt sind, und eine destination selbst ist nur ein Paar öffentlicher Schlüssel und ein Zertifikat. DNS-ähnliche Systeme hingegen erlauben es jedem der Nameserver im Lookup-Pfad, einfache Denial-of-Service- und Spoofing-Angriffe durchzuführen. Das Hinzufügen eines Zertifikats, das die Antworten als von einer zentralisierten Zertifizierungsstelle signiert authentifiziert, würde viele der Probleme mit feindlichen Nameservern lösen, aber Replay-Angriffe sowie Angriffe durch feindliche Zertifizierungsstellen offen lassen.

Abstimmungsbasierte Namensgebung ist ebenfalls gefährlich, insbesondere angesichts der Wirksamkeit von Sybil-Angriffen in anonymen Systemen — der Angreifer kann einfach eine beliebig hohe Anzahl von Peers erstellen und mit jedem „abstimmen", um einen bestimmten Namen zu übernehmen. Proof-of-Work-Verfahren können verwendet werden, um Identitäten kostenpflichtig zu machen, aber wenn das Netzwerk wächst, wird die erforderliche Last, um alle zu kontaktieren und Online-Abstimmungen durchzuführen, undurchführbar, oder wenn nicht das gesamte Netzwerk abgefragt wird, können unterschiedliche Antworten erreichbar sein.

Wie beim Internet hält I2P jedoch das Design und den Betrieb eines Benennungssystems aus der (IP-ähnlichen) Kommunikationsschicht heraus. Die mitgelieferte Benennungsbibliothek enthält eine einfache Service-Provider-Schnittstelle, in die alternative Benennungssysteme eingesteckt werden können, wodurch Endbenutzer bestimmen können, welche Art von Benennungs-Kompromissen sie bevorzugen.

I2PTunnel

Entwickelt von: mihi

I2PTunnel ist wahrscheinlich I2Ps beliebteste und vielseitigste Client-Anwendung, die generisches Proxying sowohl in als auch aus dem I2P-Netzwerk ermöglicht. I2PTunnel kann als vier separate Proxying-Anwendungen betrachtet werden — ein “client”, der eingehende TCP-Verbindungen empfängt und sie an ein bestimmtes I2P destination weiterleitet, ein “httpclient” (auch “eepproxy” genannt), der wie ein HTTP-Proxy agiert und die Anfragen an das entsprechende I2P destination weiterleitet (nach Abfrage des Namensdienstes falls nötig), ein “server”, der eingehende I2P-Streaming-Verbindungen an einem destination empfängt und sie an einen bestimmten TCP-Host+Port weiterleitet, und ein “httpserver”, der den “server” erweitert, indem er die HTTP-Anfragen und -Antworten analysiert, um einen sichereren Betrieb zu ermöglichen. Es gibt eine zusätzliche “socksclient”-Anwendung, aber ihre Verwendung wird aus den zuvor erwähnten Gründen nicht empfohlen.

I2P selbst ist kein Outproxy-Netzwerk — die Anonymitäts- und Sicherheitsbedenken, die einem Mix-Netzwerk innewohnen, welches Daten in das Mix-Netzwerk hinein und aus ihm heraus weiterleitet, haben dazu geführt, dass sich I2Ps Design darauf konzentriert, ein anonymes Netzwerk bereitzustellen, das die Bedürfnisse der Benutzer erfüllen kann, ohne externe Ressourcen zu benötigen. Die I2PTunnel “httpclient”-Anwendung bietet jedoch eine Schnittstelle für Outproxying — wenn der angeforderte Hostname nicht auf “.i2p” endet, wählt sie ein zufälliges Ziel aus einer benutzerdefinierten Sammlung von Outproxies aus und leitet die Anfrage an diese weiter. Diese Ziele sind einfach I2PTunnel “server”-Instanzen, die von Freiwilligen betrieben werden, die sich explizit dafür entschieden haben, Outproxies zu betreiben — niemand ist standardmäßig ein Outproxy, und das Betreiben eines Outproxies teilt anderen nicht automatisch mit, dass sie über einen proxyen sollen. Während Outproxies inhärente Schwächen haben, bieten sie einen einfachen Machbarkeitsnachweis für die Nutzung von I2P und stellen eine gewisse Funktionalität unter einem Bedrohungsmodell bereit, das für einige Benutzer ausreichend sein könnte.

I2PTunnel ermöglicht die meisten verwendeten Anwendungen. Ein “httpserver”, der auf einen Webserver zeigt, ermöglicht es jedem, seine eigene anonyme Website (oder “I2P Site”) zu betreiben — ein Webserver ist zu diesem Zweck mit I2P gebündelt, aber jeder Webserver kann verwendet werden. Jeder kann einen “client” betreiben, der auf einen der anonym gehosteten IRC-Server zeigt, von denen jeder einen “server” betreibt, der auf seinen lokalen IRCd zeigt und zwischen IRCds über ihre eigenen “client” tunnel kommuniziert. Endnutzer haben auch “client” tunnel, die auf I2Pmail’s POP3- und SMTP-Ziele zeigen (die wiederum einfach “server”-Instanzen sind, die auf POP3- und SMTP-Server zeigen), sowie “client” tunnel, die auf I2Ps CVS-Server zeigen und anonyme Entwicklung ermöglichen. Zeitweise haben Leute sogar “client” Proxies betrieben, um auf die “server”-Instanzen zuzugreifen, die auf einen NNTP-Server zeigen.

I2PSnark

I2PSnark entwickelt: jrandom, et al, portiert von mjw ’s Snark Client

Im Lieferumfang der I2P-Installation enthalten, bietet I2PSnark einen einfachen anonymen BitTorrent-Client mit Multitorrent-Funktionalität, der alle Funktionen über eine einfache HTML-Weboberfläche zur Verfügung stellt.

I2Pmail / Susimail

Entwickelt von: postman, susi23, mastiejaner

I2Pmail ist eher ein Service als eine Anwendung — postman bietet sowohl interne als auch externe E-Mail mit POP3- und SMTP-Service durch I2PTunnel-Instanzen, die auf eine Reihe von Komponenten zugreifen, die mit mastiejaner entwickelt wurden, und ermöglicht es Menschen, ihre bevorzugten E-Mail-Clients zu verwenden, um pseudonym E-Mails zu senden und zu empfangen. Da jedoch die meisten E-Mail-Clients erhebliche identifizierende Informationen preisgeben, bündelt I2P susi23’s webbasierten susimail-Client, der speziell mit Blick auf I2Ps Anonymitätsbedürfnisse entwickelt wurde. Der I2Pmail/mail.i2p-Service bietet transparente Virenfilterung sowie Denial-of-Service-Schutz mit hashcash-erweiterten Kontingenten. Darüber hinaus hat jeder Benutzer die Kontrolle über seine Batch-Strategie vor der Zustellung über die mail.i2p-Outproxies, die getrennt von den mail.i2p-SMTP- und POP3-Servern sind — sowohl die Outproxies als auch die Inproxies kommunizieren mit den mail.i2p-SMTP- und POP3-Servern über I2P selbst, sodass die Kompromittierung dieser nicht-anonymen Standorte keinen Zugang zu den E-Mail-Konten oder Aktivitätsmustern des Benutzers ermöglicht.

Einführung