EOF

Es gibt natuerlich bereits Ansaetze zu 'sicherer' verschluesselter Kommunikation, jedoch haben alle gerade im Umlauf befindlichen Lösungen markante Defizite: IRC ist unverschluesselt, und selbst IRC-SSL loest nicht alle Probleme: So ist die Server-zu-Server-Kommunikation meist weiterhin ablauschbar, und die Clients sind gezwungen, sämtlichen am Netzwerk teilnehmenden Serverbetreibern zu vertrau- en. Sowohl die Alternative SILC als auch das "fish" Plugin für einige IRC-Clients machen aktuell einen sehr unausgereiften Eindruck, und gaben in der Vergangenheit, und auch jetzt noch, Anlass zu derben Sicherheitsbedenken. Außerdem stört, dass nicht bereits etablierte Standards wie SSL oder GPG genutzt werden, sondern das Crypto-Rad neu erfunden wurde, weswegen ein Audit des gesam- ten Systems wesentlich diffiziler ist als beim Aufbau auf stabilen, halbwegs sicheren, Komponenten. Kommunikation über TOR (Tor Onion Routing) ist aktuell schon recht nett, ist aber für Schnüffler mit zu geringem Aufwand zu brechen, da die Routen der Pakete über einen gewissen Zeitraum sta- bil bleiben und von den Teilnehmern relativ einfach getraced werden können. Mittels statistischer Analyse ist zudem wohl mit verhältnismäßig erstaunlich geringem Aufwand (und die Blackboxen der großen Brüder stehen schon lange bei jedem ISP - und niemand weiß, wie viele TOR-Fnords von der Regierung betrieben werden) zuordenbar, dass ein bestimmtes Paket mit hoher Wahrscheinlichkeit die Response auf ein zeitlich eher gesendetes gewesen sein muss. Realisiert werden soll das ganze mit chaotischem (erisianischem :-), verschlüsseltem Onion-Routing: Es gibt keinerlei fixe Pfade für die Datenpakete, sondern jeder Teilnehmer sendet einfach verpeilt irgendwo hin an einen oder mehrere Peers. Zudem werden von sämtlichen Teilnehmern kontinuierlich Fake-Pakete (aus /dev/random o.dgl.) verschickt, um statistische Zuordnungen nahezu unmöglich zu machen. Der 'echte' Traffic, der beim angestrebten Content (vorrangig Chat und Mail) absolut nicht von großer Menge ist, geht für Beobachter einfach komplett im Noise unter. Jeder Node verschlüsselt beim Erhalt eines Paketes dieses neu und schickt es $IRGENDWOHIN weiter. Irgendwann werden dann zufällig mal für ihn bestimmte Daten ankommen (oder auch nicht ;-). Es ist klar, dass die Soft- ware, die an der Kommunikation in einem solchen Netz teilnimmt, immens gute Algorithmen braucht, um eine auch nur halbwegs akzeptable Skalierbarkeit zu gewährleisten. Außerdem sollte irgendwie der Erhalt der Daten auch acknowledged werden können, worauf aber geachtet werden muss, dass der Rückkanal nicht zu offensichtlich statistisch zuordenbar wird! Auf jeden Fall sollten vor der Imple- mentierung der eigentlichen Weichware, und wohl auch am geschicktesten noch vor dem Schreiben der letztendlichen Spezifikation, intensive Simulationen durchgeführt werden, die aufzeigen, wie, wo und wann das Programm in spe dann an Parametern wie Datenrate der Noise-Erzeugung, Anzahl der Peers, an die multicasted werden soll, wann ein Paket wieder zufällig verworfen werden soll (da natür- lich ansonsten der Traffic exponenziell steigen würde und das Netz sofort zusammenbrechen würde), und so fort, drehen müssen wird. Die Simulationen werden auch zeigen, ob die natürlich inhärent hohe Latenz Realtime-Kommunikation überhaupt ermöglicht, oder ob das Ganze doch nur für Messaging verwendet werden kann, was aber auch schon nicht zu verachten wäre.