Diskussion:Mix (Netzwerk)
Ich kann leider die angegebene Literatur nicht öffnen :-( (HTTP Fehler 403, unberechtigter Zugriff, mit allen Browsern, auch über Proxy) David Chaum: http://world.std.com/~franl/crypto/chaum-acm-1981.html Gibt es Ersatz-Literatur/Link oder ist der Fehler vielleicht nur vorübergehend? --Martin Wantke 22:13, 18. Okt. 2008 (CEST)
- mal sehen, ob ich das noch irgendwo finde. in der zwischenzeit hier der passende Link der wayback-maschine. gruß --Murkel (anmurkeln) 22:59, 18. Okt. 2008 (CEST)
- link ist nun wieder aktiv. gruß --Murkel (anmurkeln) 13:31, 19. Okt. 2008 (CEST)
- thx.--Martin Wantke 14:11, 23. Okt. 2008 (CEST)
- link ist nun wieder aktiv. gruß --Murkel (anmurkeln) 13:31, 19. Okt. 2008 (CEST)
Dummy-Traffic-Problem
Im Artikel heißt es im Moment im Bereich zu den Anwendungen und insbesondere den sich daraus ergebenden Problemen beim Sammeln / Umsortieren in Echtzeitanonymisierungsdiensten: Dieses Problem lässt sich aber mit Dummy Traffic lösen: Wenn sich während eines Sammelschrittes nur wenige echte Nachrichten im System befinden, können die inaktiven Teilnehmer Leernachrichten senden. Diese sind äußerlich nicht von echten Nachrichten zu unterscheiden und dienen zur Verwirrung des Angreifers. Die Leernachrichten können vom letzten Mix verworfen werden. Im Gegensatz zu Tor setzt JAP solchen Dummy Traffic ein.
Das ist so gesehen falsch. Das Problem bei realen Echtzeitanonymisierungsdiensten ist nicht, dass man noch mehr Nachrichten braucht. Die Dienste sind so schon langsam genug, weil sie in der Regel vollkommen überlastet sind (zumindest die kostenlosen). Das Problem sind die kurzen maximal vertretbaren Verzögerungszeiten zusammen mit der Kapazität der Anbindung der Mixe. Da sich in heterogenen Netzwerken Uniformität aller Teilnehmer bei Echtzeitanonymisierungsdiensten nicht darstellen lässt (z. B. schon Modem-Anbindung vs. DSL), wenn man nicht den langsamsten Teilnehmer als Referenz nehmen will, wird man durch Überwachung übertragener Datenvolumen bzw. Timing-Analysen (wer sendet / empfängt wann) als Angreifer immer nach recht kurzer Zeit zum Ziel kommen. Insoweit wäre Dummy-Traffic da nur eine sehr teure Verschwendung von Übertragungskapazität ohne realen Anonymitätsgewinn.
Auch setzt JAP derartigen Dummy-Traffic nicht ein. Der Dummy-Traffic bei JAP besteht lediglich aus einer Art Keep-Alive-Nachricht auf der Verbindung zum ersten Mix (er wird auch direkt dort ausgefiltert und nicht erst beim letzten Mix) - er soll gar nicht der Verbesserung der Anonymität dienen. Für eine anonymitätsfördernde Wirkung wären auch die Abstände (mehrere Sekunden) viel zu groß und nebenbei erfolgt der Dummy-Traffic in regelmäßigen Abständen, so dass ein Angreifer ohnehin wüsste, ob es sich um ein reguläres Paket oder ein Dummy-Paket handelt und es somit streichen könnte. Ein Vergleich zu Tor in diesem Punkt hat ebenfalls keinen Sinn, weil Dummy-Traffic bei dem von Tor gewählten Anonymitätsmodell keine Wirkung hätte. Man geht dort davon aus, dass nur relativ wenige Verbindungen gleichzeitig über eine Node laufen und somit ein Sammeln und Umsortieren von Nachrichten wenig zusätzliche Anonymität bringen würde. Ein Angreifer, der eine Node von außen überwacht, wird entsprechend dem Angreifermodell durch übertragene Datenmengen, Timing-Analysen, ... ohnehin alle Verbindungen durch die Node ohne Probleme hindurch verfolgen können. Das Angreifermodell geht dort davon aus, dass ein Angreifer derartige Überwachungen aber nur räumlich begrenzt durchführen kann und somit nur wenige Nodes unter Kontrolle hat. Bezogen auf die gesamte Knotenanzahl soll die Wahrscheinlichkeit also relativ gering sein, dass man mehrere Nodes aus seinem Kontrollbereich innerhalb der eigenen Route (insbesondere an erster und letzter Stelle) auswählt.
Aus den benannten Gründen werde ich die Sätze streichen.--Entzücklopädie 17:32, 19. Aug. 2010 (CEST)
- Okay, das klingt überzeugend. Was den Dummy-Traffic bei JAP betrifft, habe ich auch nochmal nachrecherchiert und die bezeichnen da in der Tat Keep-Alive-Nachrichten als solchen. Insofern ist die Löschung der Sätze absolut gerechtfertigt. Danke fürs aufmerksame Korrekturlesen! -- Bananenfalter 22:00, 20. Aug. 2010 (CEST)
Defekter Weblink
Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
---|
|
- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.3781&rep=rep1&type=pdf
- Wechsel zwischen http und https erforderlich
– GiftBot (Diskussion) 06:56, 27. Dez. 2015 (CET)