Die Information hier dient als Denkpapier, einiges kann sich noch ändern!

Die Information ist bereits nach wenigen Monaten veraltet, ich behalte es nur aus historischen Gründen.

I2P

I2P Share

Der Permalink zu diesem Text lautet permalink.de/tino/i2p4

Status

Dies ist ein alter Denkansatz, nicht einmal eine Forderung oder ein Vorschlag.

Inzwischen ist Clunk vermutlich der bessere Ansatz!

Das Problem

Jedes Netzwerk hat ein Problem, unter I2P ist dieses Problem besonders deutlich, unter Freenet ist das Problem immanent:

• Hosts sind nicht erreichbar.
  
• Hosts verschwinden (natürlich durch Aufgabe, unnatürlich durch Verbot).
• Informationen werden korrumpiert (absichtlich oder unabsichtlich)
• Der Datenzugriff ist langsam.
  

Freenet hat einen interessanten Ansatz, ines die Information als zentralen Ansatzpunkt besitzt. Der Nachteil dieses Ansatzes ist aber, dass er einige Probleme mit sich bringt:

• Man speichert nicht die Informationen, die es einem Wert sind, sondern irgendetwas. Das dient dazu, Verfolgung zu verhindern, denn niemand kann sagen, was ich gespeichert habe. Der Nachteil ist, dass das, was es mir Wert ist, leider ebenfalls verschwindet.
• An die Informationen kommt man u. U. nur sehr schwer heran, weil der Host, auf dem sie lagert, ein kleinen Uplink hat, aber einen gigantischen Downlink. So sind 6 MBit-DSLs mit 64 kBit Uplink (z. B. Satellit mit ISDN-Rückkanal) keine Seltenheit.
• Es gibt kein "Streaming". Ich kann interessante Angebote für mich nicht adressieren.

Deshalb wird ein anderer Ansatz benötigt um Informationen zu verteilen.

I2P

• Es ist zwar nach dem Internet modelliert, aber die eepsites sind nur ein Aufsatz darauf. Im Prinzip ist es ein Proxy für den Browser der die eepsites "einfach so einblendet". Das ist gut so, wie es ist, weil es transparent anonymes Browsing ermöglicht.
• Aber es bringt genau die Schwierigkeiten mit sich, die man im WWW hat. Hier wurde ein Nicht-P2P-Problem im P2P modelliert, der P2P-Gedanke geht dabei vollkommen unter.

Datenverteilung

Es gibt interessante Ansätze als Aufsätze zum Web. Dies sind vor allem RSS-Feeds.

Eigentlich ist krank, was für Kopfstände gemacht werden, um genau eines zu erreichen:

• Es werden Seiten definiert, die Daten enthalten, die andere runterladen können.
• Das ganze wird kompliziert in irgendwelchen Datenstrukturen gepackt.
• Und es gibt Aufsätze, die es einem relativ leicht machen, große Dateien runterzuladen. Dazu gehört vor allem BitTorrent.

Der Wunsch

Was hindert uns daran, das zu ändern? I2P ist relativ neu, jetzt ist der Zeitpunkt da, eine neue Weiche zu stellen, damit die Informationsverteilung so funktioniert, wie sie funktionieren sollte:

• Automatisch
  
• Transparent
  
• Sicher
  
• Anonym
  
• Und vor allem: Leicht zu bedienen!
  

Ziel ist also ein Aufsatz auf I2P der folgendes erledigt:

• Ansehen ist so einfach wie surfen.
  
• Herunterladen ist so einfach wie surfen.
  
• Hochladen ist so einfach wie surfen.
  
• Archivieren ist so einfach wie surfen.
  

Und alles funktioniert wahlweise im Pull- oder im Push-Betrieb, ohne dass man sich darüber Gedanken machen muss.

Der Ansatz von I2Pshare

Idee

Ich lasse I2Pshare in meinem Intranet laufen. Dieses I2Pshare erlaubt keinerlei Verbindungen von außen!

Ich ändere meine Dateien auf der Festplatte, stoße den Publish-Modus an und die Daten wandern, ohne weiteres Zutun, tröpfchenweise, vollautomatisch, unter automatischer Wiederaufnahme nach Verbindungsabbrüchen und sonstigen Problemen, auf meinen Verteilknoten, der diese Informationen als eepsite veröffentlich und ausserdem für andere I2Pshare-Nutzer feilhält.

Surfer wollen sich das neue Zeug runterladen, aber meine eepsite ist total überlastet. Auf ihr steht aber, man kann auch I2Pshare verwenden.

Die Leute greifen also über I2Pshare auf meine eepsite zu, und organisieren sich so zu einem Schwarm. Statt das 3 GB ISO von meiner eepsite runterzuziehen und nach 2.9 GB ständig einen fatalen Abbruch zu erleiden, holt sich jeder nur ein anderes Stückchen, gibt das an andere weiter und alle sind glücklich.

Weil ich interessante Infos habe, abonnieren sie mein I2Pshare, und bekommen so immer frisch die Updates auf ihre Platte.

Begriffe

• Daten: Öffentliche bzw. veröffentlichte Information
• Source: Das ist die Quelle von Daten.
  
• Dest: Das ist das Ziel von Daten.
  
• Pool: Hält die Daten für das Abholen bereit.
  
• Ark: Archivierte Daten
  

Die Begriffe werden hauptsächlich so gebraucht:

• Source: Es werden Daten hochgeladen, schmalbandig.
• Dest: Es werden Daten heruntergeladen, evtl. schmalbandig.
• Pool: Dort kann sich jeder bedienen, öffentlicher Zugang.
• Ark: Dort bedient man sich nur, wenn es notwendig ist.

Wichtig ist: Nur die Source verfügt über einen Private Key über den sie die Uploads autorisiert.

Datenspeicher

Die Hauptfunktion von I2Pshare ist die Verwaltung von Daten. Es bietet dafür 3 Zugänge:

• Filesystem: Die Daten werden im Filesystem aufbewahrt.
  • Die Daten in I2Pshare sind entsprechend des Files&Folders-Paradigma organisiert.
  • Namen sind in 7-Bit ASCII geschrieben. Folgende Zeiche sind in Namen erlaubt:
    • Alpha und Numerisch: a-z 0-9
      
    • Grossbuchstaben werden automatisch klein gewandelt
    • Sonderzeichen: ( ) + , - . @ _
      
    • Sonderzeichen sind am Anfang von Namen unzulässig
      
    • Nicht erlaubte Zeichen: Leerzeichen ! " # $ & ' * / : ; < = > ? \ ^ ` |
      
    • %XX ist ein Escape, wobei xx zwei hexadezimale Ziffern sind
    • %uYYXX ist ein Unicode-Escape wobei YY nicht 00 sein kann
  • Die Verzeichnisse werden automatisch reduziert
    
    • Verzeichnistrennzeichen ist /
      
    • Pfade beginnen immer mit / ./ oder ../
      
    • Pfade die nicht mit / beginnnen sind relativ. Diesen wird der Pfad des aktuellen Verzeichnisses vorangestellt.
    • Danach wird von links aus reduziert bis es nicht mehr weiter geht:
      • // ist gleichbedeutend mit /
        
      • /./ ist gleichbedeutend mit /
        
      • .. ist das Parentalverzeichnis, das vorherige Verzeichnis wird ignoriert
    • Nach der Reduktion gilt:
      
      • Am Anfang eines Pfades steht immer ein /
        
      • Am Ende eines Pfades steht immer ein /
        
      • Es kommt kein /. darinnen vor
        
    • Nach der Verzeichnisreduktion werden die Namen reduziert
    • Kommen nicht erlaubte Zeichen oder falsche Pfade vor, wird hart abgebrochen
    • %u00XX wird zu %XX reduziert
      
    • %XX wird reduziert auf eines der erlaubten Zeichen, wenn XX für solch eines steht
    • Leerzeichen werden als ^ interpretiert.
      
    • "/Sonderzeichen" wird zu /%XX geändert
      
    • Alle vom Dateisystem nicht unterstützten Zeichen werden zu %XX geändert
    • Zu lange Teilpfade werden mit einer Sequenz #/# segmentiert, wobei # für eines der oben genannten nicht erlaubten Zeichen steht. Das geht auch innerhalb %-Sequenzen.
  • Verzeichnisse sind listbar. Es gibt kein index.html oder ähnlich.
• Browser: Es gibt einen Proxy der auf dieses Filesystem zugreift.
• I2P-Protokoll: Es gibt einen I2P-Tunnel über den Verbindungen von anderen I2Pshares angenommen werden kann. Dieser dient auch für direkte I2P-Kopplung.

Die Daten stammen dabei von Quellen. Die Quelle kann eine eepsite sein, oder eine Source. Ich empfehle, dass man Sources werden typischerweise als pool.name.i2p oder ark.name.i2p veröffentlicht, je nach Nutzungstyp.

Nutzungstypen

Der Sender der Daten bestimmt die Geschwindigkeit. Der Empfänger bestimmt wie viele Verbindungen er zulässt.

• Source: Upload only. Source verbindet sich mit einer Dest, das kann entweder ein Ark oder ein Pool sein.
• Dest: Download only. Dest verbindet sich mit einer Ark oder Pool oder erlaubt eine Verbindung von Source.
• Pool: Ist eine spezielle Source die viele Verbindungen annimmt. Der Pool wird meistens automatisch verwaltet.
• Ark: Ist eine spezielle Source, die wenige Verbindungen annimmt. Der Ark wird meistens manuell verwaltet. Zu einer ark verbindet sich I2Pshare nur, wenn es im Pool nichts findet.

In der Regel sollte eine Dest immer auch ein Pool oder eine Ark sein, dies wird aber nicht erzwungen. Die Emfpehlung lautet:

• Leute mit nahezu symmetrischen Verbindungen (Uplink mindestens 500 kBit/s) sollten Pool einstellen.
• Leute mit asymmetrischen Verbindungen (Uplink mehr als 64 kBit/s) sollten Ark einstellen.
• Leute mit Problemen (Uplink unter 64 kBit/s) schalten das Feature ab. In diesem Fall verlieren sie aber die Trigger-Möglichkeit und somit den automatischen Push neuer Information und nehmen nicht direkt am Schwarm teil.

Trigger und Schwarm

• I2Pshare verteilt Informationen per Push und per Pull. Push ist, wenn eine Source zur Dest verbindet, während Pull ist, wenn die Dest zur Source verbindet.
• Die Verbindung von der Source zur Dest kann manuell geschehen (direkter Datentransfer) oder automatisch (Trigger).
• Um den Trigger zu verwenden, muss die Dest von aussen erreichbar sein (einen Tunnel offen haben).
• Die Dest sendet an die Source, welche Daten sie hat, welche Daten sie haben will und wie der Tunnel lautet, der kontaktiert werden soll.
• Die Source antwortet darauf mit einer Liste möglicher alternativer Quellen die man kontaktieren kann. Gleichzeitig trägt sie den Tunnel in die Liste alternativer Quellen für den Teil ein, den die Dest schon kennt.
• Wenn die Dest dann tatsächlich eine der Quellen kontaktieren konnte, schickt sie einen Update an die Source und teilt ihr so mit, welche andere Quelle noch lebendig ist.

Das gute an I2P ist, dass sich der Tunnel nie ändert! Die Source wird also die Dest kontaktieren, sobald sie die gewünschten Informationen hat. Dazu erlaubt der Trigger das "Abo", also Daten anzufordern, die noch gar nicht existieren.

Realisierung

Am Anfang steht die eepsite. I2Pshare ergänzt diese eepsite lediglich durch eine Verzeichnis-, Download und Upload-Funktion wie folgt:

• I2Pshare auf dem Router abonniert meine Source. Alles, was die Source an meinen Pool schickt wandert dann automatisch auf die Platte. Damit wird die eepsite automatisch befüllt.
• Zuhause kann ich dann meinen Dateitree verändern und hochladen.
• Dazu gibt es das I2Pshare-Protokoll, das sehr einfach aufgebaut ist. I2Pshare ist nämlich normales HTTP mit einem speziellen Zusatz.

I2Pshare

I2Pshare ergänzt die eepsite um

• eine virtuelle unendlich groß wachsende Datei.
  
• Für jede dieser Dateien ein Dateiindex.
  
• Für jede dieser Dateien Historyinformationen.
  
• Für jede dieser Dateien der öffentliche Schlüssel der Source.
• Optionale weitere Dateien die nach der virtuellen Datei benannt sind.

Man kann diese Informationen ganz normal per Browser abrufen.

Die Dateien der eepsite werden mittels des Dateiindexes virtuell in eine einzige große Datei "gemappt". Die Datei entspricht dabei dem Inhalt der gesamten eepsite. Aus dieser Datei werden dann per Byterange die entsprechenden Blöcke herausgeschnitten die man haben will.

Es kann mehrere Dateien geben. Das entspricht den "Abos" die I2Pshare kennt.

Die History-Informationen dienen dazu, die Bereiche der Datei zu markieren, die nicht vorhanden sind während der Dateiindex immer Prüfsumme, Größe und Position im Dateiindex enthalten.

Alles ausser der virtuellen Datei existiert physikalisch, die unendlich große Datei ist vollständig virtuell und in Wirklichkeit das Verzeichnis, in dem die ausgepackten Dateien liegen. I2Pshare sorgt transparent dafür, dass die entsprechenden Byte-Bereich dann durch den Inhalt der Dateien im Verzeichnis auf der Platte ersetzt werden. In Zukunft wird es wohl auch einen "Lookup" und einen "Search" geben, mit dessen Hilfe man Teilschnitte aus dem Dateiindex usw. erfahren kann.

Der Dateiindex ist einem ewigen Logfile sehr ähnlich und kann nur wachsen. Deshalb sind die Dateien immer mit einem Timestamp versehen, so dass sie umbenannt werden, wenn sie schrumpfen oder sich alte Inhalte verändert haben sollten. In Wirklichkeit wird ja nur der Dateiindex neu erzeugt.

Dateiindex

Der Dateiindex ist ähnlich eines ewigen Logfiles aufgebaut. Die Felder sind durch Leerzeichen voneinander getrennt.

• MD5-Summe der Datei
  
• Name der Datei (dieser enthält per Definition kein Leerzeichen!)
• Größe der Datei
  
• Optional eine Anzahl Angaben von Offset:Länge (Zukunftsfeature)
• Offset der Daten in der virtuellen Datei
  
• Ein Linefeed
  

Alle Zahlen sind hexadezimal. Ist die MD5-Summe ein X dann gilt die Datei als gelöscht. Eine zweite Möglichkeit, eine Datei zu löschen ist, ihren Block im History-File mit einem X zu versehen.

Ab und zu erscheint außerdem eine Zeile der Form

Diese können eigentlich alle, bis auf die letzte, ignoriert werden. Version ist eine versionsnummer des Signaturalgorithmus, Timestamp ist eine beliebige Zahl

SIGN signiert die Datei bis (ausschließlich) der Signatur mit dem privaten Schlüssel der Quelle. Das heißt, die Datei einschließlich "timestamp ", also auch das Leerzeichen vor der Signatur!

Spätere Signaturen unterschreiben dabei die vorherigen Signaturzeilen ebenfalls.

History

Das History ist für den Neustart und die Integritätsprüfung notwendig. Es verändert sich laufend.

Es enthält Zeilen der folgenden Form:

• Länge: Länge des Blocks in hexadezimaler Schreibweise.
• Bitshift der Längenangabe mit G=1, P=10, Z=20. 1G wäre 1 Byte, 1Z wäre 1 MB. 1 MB ist übrigens die maximal empfohlene Blockgröße für bekannte Daten.
• Inhalt: Die Angabe, was enthalten ist:
  
  • für bekannte Daten steht hier die MD5-Summe in hexadezimaler Form
  • ? steht für unbekannter Block
    
  • X steht für gelöschter bzw. unerwünschter Block
    
  • Zahl steht für Anzahl der Retries dieses Blocks
    
• Optional ein Leerzeichen und irgendwelche zukünftigen Erweiterungen
• Ein Linefeed
  

Keyfile

Das Keyfile dient nicht nur dazu, die Source im Schwarm ausfindig zu machen von der die Daten stammten, und evtl. Alternativen zu finden die ebenfalls diese Source kennen, sondern auch um den Upload neuer Informationen zu autorisieren.

Optionen

Die Autorisierung zum Upload wird über den Eintrag in der Abo-Datei erzeugt. In dieser befindet sich der öffentliche Schlüssel der Source, die auf die Index-Datei schreiben darf.

In der Praxis

Beispiel 1: Upload und Verteilung

Alice hat viele Dateien die sie anderen zur Verfügung stellen will. Aber Alice hat nur eine kleine dünne Internetanbindung.

Bob hingegen will gerne die Dateien haben, und Bob hat eine echt dicke Leitung.

• Alice erzeugt in ihrem Router einen Server-Tunnel zu I2Pshare und schickt den öffentlichen Key an Bob. Alice aktiviert den Tunnel aber nicht.
• Bob erzeugt einen Server-Tunnel im I2P der auf seine I2Pshare-Anwendung zeigt, aktiviert den Tunnel, und gibt öffentlichen Key an Alice. Danach erzeugt er die Abo-Datei und kopiert den öffentlichen Schlüssel von Alice hinein.
• Per I2Pshare "packetiert" Alice die Daten, erzeugt also den Dateiindex, und lädt diesen an Bob hoch. Bobs Rechner akzeptiert die Datei, da die Signaturen mit einer Abo-Datei übereinstimmt. I2Pshare bei Bob erzeugt dadurch Verzeichnis und alle weiteren notwendigen Dateien.
• Danach instruiert Alice ihr I2Pshare, die Daten an Bob hochzuladen. Da eine Abo-Datei existiert, akzeptiert Bobs Rechner neue Blöcke in der virtuellen Datei.
• Bob veröffentlicht die hochgeladenen Seiten auf seiner eepsite und nennt auch seinen I2Pshare-Zugang für andere. Diese können so Bobs I2Pshare nach Alice Dateien fragen. Bobs I2Pshare dient so automatisch auch als Tracker.
• Alice bekommt einen größeren Internetzugang und entschließt sich, ihre Source ebenfalls freizugeben. Dazu aktiviert sie lediglich den bisher nicht aktivierten Tunnel.

Alice erzeugt einen Client-Tunnel zu Bob und verbindet I2Pshare mit diesem Tunnel.

Beispiel 2: Nutzung

Charlie ist an den Daten von Alice interessiert nachdem er auf Bobs eepsite auf die Informationen gestoßen ist. Er möchte eine ganze Reihe davon haben.

• Charlie hat schon I2Pshare installiert. Deshalb wechselt er im Browser auf den I2Pshare-Proxy und spricht darüber Bobs I2Pshare an.
• I2Pshare erlernt was Bob über die Daten von Alice weiß. Das geht sehr einfach indem der Indexfile und Keyfile heruntergeladen werden. Genau so wie es zwischen Bob von Alice lief.
• Der Proxy blendet dann die Daten von Alice ein, als wären sie von einer Eepsite.
• Charlie kann bequem surfen. Ist die Datei noch nicht heruntergeladen, passiert das automatisch beim ersten Mal, danach ist sie lokal auf Platte abgelegt.
• Charlie kann sie sich danach auch im Explorer ansehen und braucht keinen Browser.
• Es ist auch ein größeres ISO-Image darunter auf den Charlie nicht warten möchte. Also fängt er den Download an und bricht ihn dann aber ab. I2Pshare lädt die Datei aber weiter im Hintergrund herunter, allerdings mit niedriger Priorität.
• Am nächsten Tag brennt er sich die heruntergeladene CD und findet, was darauf ist, sehr interessant. Deshalb beschließt er, alles, was Alice anbietet, komplett herunterzuladen. Alles was er machen muss ist den Keyfile kopieren und die Abo-Datei anlegen.

Beispiel 3: Trigger

• Charlie hat sein I2Pshare triggerfähig gemacht. Dadurch hat sein I2P einen Trigger an Bob ausgesendet und Bob hat ihm die anderen Quellen genannt, die er kennt.
• Deshalb ist Charlie jetzt Teil des Schwarms, der automatisch von Updates bekommt.
• Alice erweitert ihr Angebot. Sie fügt Dateien hinzu, ändert ein paar und löscht ein paar alte weg.
• Danach packetiert sie die Daten wieder mit I2Pshare. I2Pshare greift dabei nur die neuen Dateien auf und hängt sie an das Indexfile an.
• Danach aktiviert Alice wieder den Upload.
  
• Da Bob keine Archivoption eingeschaltet hat, werden die geänderten Dateien überschrieben. Mit der Archivoption würden sie umbenannt, und zwar mit einem Suffix, das der MD5-Summe der Datei entspricht.
• Da Bob aber keine Löschoption eingeschaltet hat, bleiben die alten Dateien auf der Platte. Sind Archivoption und Löschoption gemeinsam aktiv, würde die Datei nur umbenannt.
• Sobald neue Daten eintreffen, kann das I2Pshare von Bob die anderen triggerfähigen Rechner, die er ja kennt, von den neuen Daten in Kenntnis setzen.
• So bekommt Charlie vollautomatisch die neuen Daten auf die Platte gepumpt, wobei er nur einen kleinen Teil von Bob bekommen muss, die Liste der anderen triggerfähigen Teilnehmer die neue Informationen haben erfährt er ja ebenfalls von Bob.

Beispiel 4: Phönix

Alice und Bob treffen sich persönlich. Die Terroristen haben Alice aber inzwischen als die Quelle der ihnen unliebsamen Informationen ausgemacht hat und einen Killer angeheuert. Der Killer bringt Alice und Bob um.

• Nachdem sie in Alice Wohnung nicht fündig wurden finden die Terroristen in Alice Bankschließfach die externe Festplatte von Alice. Darauf ist der private Schlüssel mit dem Alice die Uploads autorisiert hat, denn Alice war nicht paranoid genug gewesen um TrueCrypt zu verwenden.
• Über diesen Schlüssel löschen die Terroristen alle Daten in I2Pshare. Diese Löschung wird per Trigger auf viele Teilnehmer weitergeleitet und von diesen auch ausgeführt.
• Danach sorgen die Terroristen dafür, dass weltweit alle Hochsicherheitsrechenzentren, die Rechner von Alice oder Bob gehouset haben könnten, mit Bombenanschlägen zerstört werden, genauso wie die zwei Wohnviertel in denen Alice und Bob lebten. Viele Freunde und Bekannten von Alice und Bob sterben ebenso am gleichen Tag durch Anschläge.
• Charlie und die anderen im Schwarm bekommen davon nur durch die Presse mit. Sie erkennen, welch brisantes Material sie da haben, und die meisten entschließen sich, die Daten lieber zu löschen, sofern überhaupt noch etwas vorhanden ist.
• Charlie aber hat keine Angst. Er hat niemals den öffentlichen Schlüssel seines I2Pshare-Tunnels mit seiner eepsite verquickt und bisher nur mit wenigen darüber geredet was er da hat. Außerdem hatte er die Archivierungsoption eingeschaltet, so dass die Löschung nicht funktionierte.
• Zur Sicherheit löscht er aber den I2Pshare-Tunnel auf seinem Router und legt einen neuen an. Das Material speichert er auf eine externe Festplatte, die er an einen anderen Rechner mit hoher Bandbreite anschließt, auf dem er einen frischen I2P-Router und I2Pshare installiert hat.
• Danach informiert er die zuständigen Behörden. Anonym, über I2Pmail, und teilt ihnen den öffentlichen Schlüssel des I2Pshare-Tunnels auf dem frisch angelegten Rechner mit.
• Die Behörden sind begeistert. Sie wissen zwar nicht, wer ihnen das Material geschickt hat, aber da Charlie die Archivoption eingeschaltet hatte können die Behörden jede Änderung der Daten nachvollziehen seit Charlie sie abonnierte. Ausserdem haben die Behörden aus den Trümmern von Alice Haus noch eine Sicherheitskopie des privaten I2P-Schlüssel wiederherstellen können, deshalb wissen sie, diese Informationen sind authentisch.
• Nachdem der Krieg zwischen der Terrororganisation und den Geheimdiensten beendet ist, startet Charlie "Alice in memoriam", eine eepsite ihr zu Gedenken. Und er veröffentlicht das Material von Alice ergänzt um alle neuen Fakten, die er zusammentragen konnte.
• Dazu repacketiert er nicht von Anfang an sondern setzt auf dem Indexfile von Alice auf. Allerdings signiert er jetzt das ständig größer werdende Indexfile mit dem privaten Schlüssel seiner I2Pshare-Anwendung.
• Als erste Datei fügt er dazu dem Archiv Alice privaten Schlüssel hinzu, damit man ihre alten Signaturen überprüfen kann.
• Er macht all das, vollständig anonym. Denn sicher ist sicher.

-Tino, 2005-09-18, updated 2005-12-18
PS: Alles was hier steht ist fiktiv!