71 lines
3.5 KiB
HTML
71 lines
3.5 KiB
HTML
{% extends "_layout_de.html" %}
|
|
{% block title %}Wie Garlic Routen funktioniert{% endblock %}
|
|
{% block content %}
|
|
<p>Die Webseite wird gerade überholt und dieses Dokument kann alte Informationen enthalten</p>
|
|
<p>
|
|
wie kurz in der <a href="how_intro_de">Einleitung</a> erklärt, benutzt I2P
|
|
in Erweiterung zum Senden von Nachrichten über Tunnel (via
|
|
<a href="how_tunnelrouting_de">Tunnels</a>) eine Technik, die sich "Garlic
|
|
Routing" nennt - schichtenweise verschlüsselung der Nachrichten und
|
|
weiterleiten durch Knoten, die der ursprüngliche Sender selektiert.
|
|
|
|
Dies ist ähnlich zu der Technik, die Mixmaster für Nachrichten nutzt
|
|
(siehe <a href="how_networkcomparisons">Netzwerk Vergleich</a>) - eine Nachricht
|
|
nehmen, verschlüsseln mit dem öffentlichen Schlüssel des Empfängers,
|
|
diese nocheinmal verschlüsseln (mitsamt den Informationen, die die nächste
|
|
Station bestimmt) und dieses wiederum mit dem öffentlichen Schlüssel
|
|
der darauffolgenden Station, bis alle Stationen im Tunnel abgearbeitet sind (und
|
|
für jede Station eine Schicht von Verschlüsselung vorhanden ist).
|
|
Der einzige signifikante Unterschied zwischen dieser Technik und dem I2P "Garlic Routen"
|
|
ist, das in jeder Schicht anstelle von nur einer Nachrich eine beliebige Anzahl
|
|
von Nachrichten vorhanden sein kann.
|
|
|
|
|
|
<p>
|
|
<img src="http://dev.i2p.net/~jrandom/wiki/garlic.png">
|
|
<p>
|
|
In Erweiterung zu dem gepacktem Paket, enthält jede entpackte "Garlic"
|
|
Nachricht eine Sender spezifische Anzahl von Fülldaten, die dem Sender einen
|
|
aktiven Schutz gegen Bandbreiten Analysen bietet
|
|
<p>
|
|
<H2>Anwendung in I2P</H2>
|
|
|
|
<p>
|
|
I2P benutzt das "Garlic Routen" in 3 Positionen:
|
|
<UL>
|
|
<li> Beim Tunnel Aufbau
|
|
<li> Um den Erfolg oder Misserfolg des Ende-Zu-Ende Transportes einer Nachricht zu ermitteln
|
|
(indem es eine weitere "DeliveryStatusMessage" in die Nutzdaten einfügt, wohingegen
|
|
an dem gepacktem Paket eine "DeliveryStatusMessage" mit Instruktionen zum Rücktransport
|
|
über andere Knoten und Tunnel angefügt wird).
|
|
|
|
<li> Zum Publizieren von einigen Netzwerk Datenbank Einträgen (verringern von der
|
|
Wahrscheinlichkeit einer erfolgreichen Traffic Analyse)
|
|
</UL>
|
|
<p>
|
|
Es existieren weitere Wege, mit denen durch diese Technik die Performance des Netzwerkes
|
|
erhöht werden kann, die Balance zwischen Transportlatenz und Durchsatz umgangen werden
|
|
kann und Daten über redundante Wege transportiert werden kann, um die
|
|
Zuverlässigkeit zu erhöhen.
|
|
<p>
|
|
<H2>Verschlüsselung</H2>
|
|
|
|
<p>
|
|
Die Verschlüsselung in jeder Schicht der "Garlic" Nachricht nutzt den
|
|
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> Algorhytmus, der die Kosten
|
|
einer vollen 2048bit ElGamal Verschlüsselung für folgende Nachrichten
|
|
vermeidet, dafür nutzt dieser einen zufälligen SessionTag, der zuvor
|
|
spezifiziert wurde und 256bit AES Verschlüsselung.
|
|
<p>
|
|
<H2>Referenzen</H2>
|
|
|
|
<p>
|
|
Der Begriff "Garlic Routen" wurde zuerst von Michael Freedman in Roger Dingledines
|
|
Freehaven <a href="http://www.freehaven.net/doc/freehaven10.ps">[Aaster Arbeit]</a>
|
|
erwähnt, welche abgeleitet war vom <a href="http://onion-router.net/">[Onion Routen]</a>.
|
|
Der Hauptunterschied beim I2P "Garlic Routen" ist der unidirektionale Weg - es gibt
|
|
keinen Umkehrpunkt, der im Onion Routen zu finden ist, oder auch keine Mixmaster Antwort
|
|
Blöcke. Dieses vereinfacht den Algorhytmus erheblich und erlaubt flexiblere
|
|
und zuverlässigere Transporte. </p>
|
|
{% endblock %}
|