P2P

Es gab und gibt einige Möglichkeiten, seine E-Mail Kommunikation zu schützen. Ihr werdet alle schon von Pretty Good Privacy (PGP) von Phil Zimmermann gehört haben; oder auch vom GNU Privacy Guard (GnuPG oder GPG), der als Free Source unter der GPL (GNU General Public License) vorliegt. Diese Programme sind sehr gut geeignet, es den Lauschern an der Wand zumindest drastisch zu erschweren, dass sie die E-Mail einfach so mitlesen können.

Aber es gibt immer noch genügend die Privatsphäre verletzende Anhaltspunkte daraus zu ziehen, wer mit wem verschlüsselte E-Mails austauscht und so stand mir der Sinn nach "höherem" ;-) Bitte nehmt das nicht wörtlich, es geht mir nicht darum, PGP oder GPG zu ersetzen oder auszustechen. Es geht um eine noch weitergehende Anonymisierung von Datenaustausch und -- wenn das möglich ist -- absolute Unzensierbarkeit von einmal verbreiteten Inhalten.

Was ist ein Peer-To-Peer Netzwerk (P2P)

Peer-To-Peer heisst auf Deutsch frei übersetzt einfach "Hand-in-Hand" oder vielleicht "Aug-in-Aug". Es geht darum, dass eine Verbindung im Internet nicht nur in der üblichen Weise von einem "Client" (einem Kunden) zu einem "Server" (dem Anbieter) hergestellt werden kann, so wie das bei den meisten üblichen Dingen wie HTTP, FTP oder auch vielen Tauschbörsen der Fall ist, sondern durchaus auch zwischen den "Kunden", also sozusagen auf privater Ebene. Dabei spielt der sonst nur passive "Kunde", also Du, dann beide Rollen: die eines Servers und eines Clients.

Der Unterschied zwischen einem Server und einem Client ist nicht sehr gross. Vor allem dann nicht, wenn der Server nicht tausende von Clients bedienen muss, wie das viele bekannte WWW-Server schaffen müssen, sondern nur einige, wenige Verbindungen. Ein P2P Netzwerk baut gerade auf diese Möglichkeit auf, ein Netzwerk aus kleinen Knotenpunkten (den sogenannten Nodes) aufzubauen, die sowohl Server als auch Client sind, aber immer nur für wenige "benachbarte" Knotenpunkte. Unter Nachbarschaft versteht man in diesem Fall natürlich keine örtliche Nähe. Gemeint ist eine Nähe im Sinne der Netzwerktopologie, also in den Internet-Verbindungen mit einigen Bekannten oder Freunden. Die können vielleicht in Deutschland, aber durchaus auch irgendwo sonst auf der Welt am Netz sein.

Sind diese Verbindungen hergestellt, können über sie dann Texte (wie E-Mails oder Botschaften wie bei ICQ) oder auch Daten ausgetauscht werden. Das können Bilder, Musik, Filme... einfach alles sein, was in elektronischer Form vorliegt. Was nun nötig ist, damit in einem P2P Netzwerk diese Daten zwischen den Knoten (den Nodes) ausgetauscht werden können, ist ein System, dass jeder Datei einen eindeutigen Schlüssel zuordnet. Es hätte z.B. wenig Sinn, die "C:\Eigene Dateien\" Verzeichnisse aller Windows Nutzer auf einem Haufen zu werfen und zu sehen, was dabei herauskommt :-) Ein bisschen mehr System sollte das Ganze schon haben, damit es keine Kollisionen bei den Namen gibt und man Dinge auch findet, wenn man weiss, wo man suchen müsste.

Über Schlüssel und Hashes - hier besonders SHA1

Der Schlüssel zur Ordnung im System ist der Schlüssel, oder der Hashwert, einer Datei. Dabei hat "Hash" nichts mit Rauschgiften zu tun, sondern steht für einen verkürzten "Sammelbegriff" für einen Datei-Inhalt. Es gibt einige verschiedene Methoden, solche eindeutigen Schlüssel für einen bestimmten Datei-Inhalt zu finden. Eine der neuesten und besten heisst mit Namen SHA1 (Secure Hash Algorithm 1) und er ist z.B. hier beschrieben.

Um die Funktion eines Hashes einmal völlig untechnisch darzustellen könntest Du annehmen, es ginge darum, einen eindeutigen Namen für jede Datei auf deiner Festplatte zu finden. Einmalig nicht nur auf deiner Festplatte, sondern weltweit (und sogar für das ganze Universum, bzw. auch alle anderen Universen). Mit Namen wie "Datei1.txt", "Datei2.txt" käme man da sicher nicht weit. Der "Trick" von SHA1 ist nun, dass er so etwas ähnliches macht, wie alle Daten aus der Datei zusammenzuaddieren und dann die Summe auszugeben. Es ist zwar kein einfaches Addieren, denn sonst wäre ja der Text "12" nicht zu unterscheiden von "21", sondern etwas komplizierter, aber der Effekt um den es geht, sollte klar werden: jeder Inhalt einer beliebigen Datei, der auch nur um ein Zeichen von einer anderen Datei abweicht, bekommt einen neuen, einmaligen und unverwechselbaren Schlüssel.

Es mag erstaunlich klingen, dass so etwas möglich sein soll, aber die Länge des Schlüssels und die Qualität des Algorithmus zur Berechnung geben den Ausschlag. Der SHA1 Hash ist 160 Bits lang und so gibt es 2 hoch 160 Möglichkeiten für verschiedene Schlüssel.
Wer erinnert sich an die Geschichte zum Reiskorn und Schachbrett? Auf das erste Feld 1 Reiskorn, auf das zweite 2, auf das dritte 4 usw. war alles, was der Erfinder des Schach vom chinesischen Kaiser für das Spiel haben wollte. Der war erfreut, dass er so billig davon kommen sollte -- und stimmte freudig dem Preis zu . Aber er hatte eben nicht zuende gerechnet. 2⁶⁴ ist immerhin etwas mehr als 1'844'674'074'000'000'000 und so viele Reiskörner dürfte es noch nicht einmal gegeben haben, seit Reis auf der Erde angebaut wird (oder vielleicht gerade so?). Jedenfalls stelle man sich nun so viele Universen mit Erden und chinesischen Kaisern vor, die sich alle verschätzt haben, wieviel Reiskörner auf dem unterschätzten Schachbrett hätten liegen sollen. In jedem Universum einen Kaiser, mit dem Problem der Unterschätzung von 2er Exponenten. Und wenn man diese Vorstellung langsam hat, dann stelle man sich nun noch einmal so viele Sammlungen von Universen vor, jedes mit einer Sammlung von Unmengen von Erden mit chinesischen Kaisern mit unbezahlbaren Mengen von noch nicht einmal gewachsenen Reiskörnern... das ist SHA1.

Nun haben wir also ein Problem gelöst: wir können jeder beliebigen Datei, ja jedem Namen, jedem Wort, jeder Version eines Textes, in dem sich auch nur ein Buchstabe geändert hat, einen eindeutigen Schlüssel zuweisen. Das ist es, was wir benötigen, um irgendjemand anders auf der Welt mitzuteilen, welche Datei, welchen Text, welches Bild oder Musikstück er von uns haben kann. Allerdings kann sich kein normaler Mensch 40stellige Hexadezimalzahlen merken (das ist die Länge von 160 Bit Zahlen in hexadezimaler Schreibweise) -- und auch nicht die bei Freenet und auch bei ENTROPY verwendete Darstellung als "base64" Zeichenkette, wo ausser Zahlen auch noch Buchstaben und einige Sonderzeichen den SHA1 Hash auf 27 Stellen verkürzen. Für Computer hingegen ist der Umgang mit 160 Bit Häppchen ein Klacks. Die verspeist er im Dutzend, sortiert, vergleicht und kopiert sie in Windeseile. Und um dem Menschen nun wieder etwas zu geben, was er sich merken kann, verwenden wir doch wieder Namen und leiten sie um zu den langen Schlüsseln.

Content Hash Keys und Key Signed Keys (CHKs und KSKs)

Die im vorigen Absatz beschriebenen Schlüssel zum Inhalt einer Datei haben im technischen Sprachgebrauch die Bezeichung Content Hash Key, also in etwa "Inhalts Sammel Schlüssel". Diese Bezeichnung ist nicht speziell für das Freenet gültig, sondern bezeichnet allgemein diese Funktion, einer Datei einen eindeutigen Wert zuzuorden. Daher verwendet auch ENTROPY den Schlüsseltyp CHK, wenn auch in vom Freenet abweichender Technik.

Ein Name im Freenet und beim ENTROPY Projekt ergibt nun ebenfalls einen eindeutigen SHA1 Wert. Dazu wird einfach der Name selbst als Text behandelt. Nun speichert man unter diesem Namen aber nicht den Inhalt einer Datei, sondern nur einen Verweis auf den SHA1, der sich aus deren Inhalt ergeben hat. Diese Art von Schlüsseln heissen bei Freenet KSK (key signed key) und auch ich habe diese Bezeichnung beibehalten. So gibt es den KSK mit dem Namen "freenet:KSK@gpl.txt" und sein Inhalt verweist auf den Text der GNU General Public License. Wenn man also im Freenet oder bei ENTROPY den Schlüssel "gpl.txt" oder "KSK@gpl.txt" oder noch ausführlicher "freenet:KSK@gpl.txt" aufruft, wird man unsichtbar weitergeleitet zu einem Schlüssel, der den eigentlichen Text beschreibt. Genauso könnte ich nun z.B. meine ganze Festplatte unter "freenet:KSK@pullmoll/festplatte/*" im Freenet veröffentlichen und die einzelnen Dateinamen bekämen jeder einen eindeutigen SHA1 Wert, der keinem anderen Namen auf der Welt entspricht. Zusätzlich zu den Namen werden auch die Referenzen bzw. Weiterleitungen auf die SHA1 Werte der Inhalte der Dateien gespeichert, und so könnte jeder, der einen Namen einer meiner Dateien kennt, den Inhalt im Freenet (oder im ENTROPY Netz) unter "freenet:KSK@pullmoll/festplatte/bekanntername.ext" finden.

Ein sehr gewünschter und positiver Nebeneffekt dieser Methode ist es, dass identische Inhalte auch identische Schlüssel ergeben. Wenn also zwei Leute genau dieselbe Datei speichern, aber unter zwei verschiedenen Namen, dann ist der Inhalt dennoch nur einmal vorhanden! Die Weiterleitung von beiden Namen geht zum selben Schlüssel.

Es ist aber wichtig festzuhalten, dass in dieser Umleitung von Namen auf den Inhalt ein ganz wesentlicher Schwachpunkt steckt. Schlüssel vom Typ KSK sind unsicher, denn der Inhalt, auf den sie verweisen, ist nicht in irgendeiner Weise festgelegt. Einfach gesagt könnten ja zwei Teilnehmer an einem Netzwerk, die nichts voneinander wissen (bzw. deren Nodes, also Netzknoten, keine direkte oder indirekte Verbindung haben), zwei völlig verschiedene Dateien unter ein und demselben Namen ins Freenet (oder eben auch ENTROPY Netz) eintragen. Das würde nur dann nicht funktionieren, wenn ein Knoten vor dem Einfügen das ganze Netz befragen könnte, ob denn der Name eventuell schon vergeben ist. Das ist aber praktisch unmöglich, weil immer einige Knoten nicht erreichbar sein werden. Als Folge kann es also zu Namenskollisionen kommen. Ein Knoten hat eine andere Auffassung davon, was nun unter freenet:KSK@gpl.txt zu finden ist wie ein anderer Knoten.

Es ist also immer zu bedenken, dass was hinter einem KSK steht, noch unsicherer und fragwürdiger ist, als das was hinter einem CHK steckt. Einen Content Hash Key zu fälschen, stellt einen grossen Aufwand dar. Ich arbeite auch gerade für ENTROPY an der Funktion, die das Eintragen von falschen CHKs in den eigenen Knoten nicht zulassen wird. Derzeit fehlt diese Absicherung noch.

Es gibt aber einen Ausweg aus dem Dilemma, das sich mit den KSKs aufzutun scheint, und dieser Ausweg heisst Sub Space Keys oder kurz SSKs. Auf Deutsch könnte man diese Schlüssel als "Unterbereichs-Schlüssel" bezeichnen.

Sub Space Keys (SSKs)

Wenn nun jeder Nutzer von Freenet oder ENTROPY seinen eigenen Bereich hätte, in dem nur er das Recht hat, etwas zu veröffentlichen, dann würde es keine Namenskollisionen mehr geben. Und es gibt diese Möglichkeit mit Hilfe der Sub Space Keys.

Ein SSK ist ein dem eigentlichen Datei- oder Verzeichnisnamen vorangestellter Schlüssel, zu dem nur einer der Teilnehmer am Netz den Zugang hat. Natürlich könnten es auch mehrere Teilnehmer sein, wenn jemand den privaten Anteil seines Schlüssels weitergibt. Aber gehen wir zunächst einmal davon aus, dass der private Schlüssel auch wirklich in einer Hand ist.

Freenet setzt hier nun ein Verfahren ein, bekannt unter dem Namen DSA (Digital Signature Algorithm), bei dem eine Signatur (also eine elektronische Unterschrift) des Absenders durch jeden Empfänger einer Nachricht -- oder einer Datei unterhalb eines SSKs im Freenet -- überprüft werden kann. Es kann also festgestellt werden, ob (mit sehr hoher Wahrscheinlichkeit) die Datei von dem Absender stammt, der dies durch die Verbreitung unterhalb seines Sub Space Keys vorgibt.

Nun ist die Errechnung von Signaturen und die Überprüfung derselben beim Empfänger ein langwieriges Geschäft. Es geht dabei um Berechnungen mit sehr grossen Zahlen, die selbst auf einem heutigen Computer eine Menge Zeit in Anspruch nehmen. Ich bin noch nicht sicher, ob sich der Aufwand lohnt, denn es geht meiner Meinung nach ja bei ENTROPY um eine anonyme Kommunikation, nicht um garantierte Echtheit der Inhalte. Man kann genaugenommen sowieso keinem Inhalt im Netzwerk zu 100% trauen, erst recht nicht in einem anonymen Netzwerk. Weiterhin kann jeder, wenn es um den Austausch von wichtigen Informationen geht, Dateien mit den bekannten Tools PGP/GPG signieren. Dazu reicht es, ein eigenes Schlüsselpaar für das Freenet (oder für ENTROPY) zu erzeugen und den Public Key zu veröffentlichen, ganz wie man das auch mit E-Mail Kommunikation machen sollte.

Wenigstens in der ersten Stufe plane ich also für ENTROPY das Einspielen von SSKs in der 'ausgelieferten Version' der Software (also in den Quellen), nur aus den zugehörigen privaten Schlüsseln zuzulassen. Natürlich kann jeder nicht völlig blöde Programmierer mit etwas Geschick diesen Teil der Software ändern, um dann unter falscher Flagge zu segeln. Aber ich will selber sehen, ob und in welchen Fällen das vorkommen würde oder wird. Bei den Dingen, die ich mit dem Netzwerk vorhabe, wäre es mir gleichgültig, wenn jemand meinen SSK manipuliert und dort Dinge veröffentlicht, die angeblich von mir kommen. Ich kann ja jederzeit ein neues Schlüsselpar erzeugen und bin nicht darauf angewiesen, dass meinem Content vertraut wird. Wenn es um Vertrauen geht, bevorzuge ich die menschlichen Kontakte noch immer den technisch realisierten.

Kürzer formuliert sehe ich die SSKs im ENTROPY Netzwerk eher als Hilfsmittel zur Vermeidung von Namenskollisionen, denn als Echtheitszertifikat. Eine Sicherheit wird sich also daraus nicht ableiten lassen. Niemand kann sagen, dass Inhalte, die unter einer meiner SSKs veröffentlicht sind auch wirklich von mir stammen -- und das gilt genauso für jeden anderen Inhalt. Wir werden sehen, ob das problematisch ist, oder ob nicht doch das Interesse an Kooperation und Austausch überwiegt.

Eine Konsequenz aus dem Gesagten ist aber unbedingt, dass Niemand ausführbare Programme direkt aus dem Netzwerk laden und installieren sollte. Wenn er das macht, riskiert er auch bei bekannten Quellen, die aber ja sowieso anonym waren, dass er einen Trojaner oder schlimmeres einschleppt.

Zum Schluss noch die Anmerkung, dass auch Freenet oder anderen mit DSA signierten Inhalten zu vertrauen bedeutet, dass man demjenigen Vertrauen schenkt, der das Programm, mit welchem eine Signatur verifiziert wird, vor der Übersetzung geprüft hat. Und nach der Übersetzung noch einmal, mit bekannten guten und schlechten Signaturen. Aber wer kann schon sicher behaupten, dass sein PGP auf dem Computer auch noch genau das PGP ist, welches eine falsche Signatur anzeigen würde? Wer überprüft bei jedem Programmstart, ob nicht ein Trojaner die pgp.exe oder /usr/local/bin/gpg manipuliert hat? Wer hat die Quelltexte der Programme selber durchgesehen und die Mathematik, deren Umsetzung und die Ergebnisse verstanden und überprüft? Ich nicht...