Ich weiß, dass dieser Thread eher weniger mit Programmierung an sich zu tun hat und mehr in die Kategorie Kryptographie fällt, aber da ich die letzten Tage mal einen Blick auf OTR geworfen hab, und die Idee dahinter recht gut finde, kam mir die Idee, soetwas ähnliches als Basis für ein anonymes Netzwerk herzunehmen.

Aber im Detail. Nehmen wir einmal an, es existiert ein geschlossenes, anonymes Netzwerk N mit den Mitgliedern Alice, Bob und Charlie. Die Kommunikation innterhalb dieses Netzwerkes verläuft anonym, aber authentifiziert - d.h. Alice und Bob können mit einander Reden, ohne jedoch die Identität des jeweiligen Gegenüber einem Dritten (z.B. Charlie oder Eve) beweisen zu können. Ferner garantiert dieses Netzwerk auf Grund der verwendeten Protokolle, dass im Nachhinein die gesamte Unterhaltung für keinen der Beteiligten nachvollziehbar ist, und Frank sogar ein gefälschtes Protokoll anfertigen kann. Soweit, so ähnlich zu OTR.

Nun möchte Dave dem Netzwerk von Alice, Bob und Charlie beitreten,
- ohne deren Identität zu kennen
- ohne seine Identität an Eve oder Mallory zu offenbahren (auch in Bezug auf Side-Channel-Angriffe)
und dabei dennoch verifizieren zu können, dass
- er im Netzwerk angekommen ist

Hintergrund: Angenommen, dieses Netzwerk dient dem freien Meinungsaustausch in einem Land, in dem eine Zensur stattfindet. Die Autoritäten dieses Landes überwachen die Kommunikationswege, d.h. dass jegliche gesendeten Informationen einsehbar und gespeichert sind. Das verwendete Protokoll und dessen Implementierung sind öffentlich bekannt. Jegliche hinterlassenen Spuren können daher, wenn sie zugeordnet werden, gegen den Nutzer ausgelegt werden. Zentrale Punkte zum Hinterlegen von Informationen sind daher zu vermeiden.

Wie müsste Daves Vorgehen sein, damit er dem Netzwerk beitreten kann?

Erleichterung: Wir nehmen an, dass die Kryptographischen Primitive (Verschlüsslung, Hashes, RNGs, Steganographie, usw.) von den beteiligten Inividuen ohne Einschränkungen eingesetz werden dürfen.

Disclaimer: Ähnlichkeiten mit real existierenden Personen, Netzwerken oder Ländern sind rein zufällig und unbeabsichtigt.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hm.. Interessante Frage
Wie würdest du "Identität" definieren? Hatte gerade einen Ansatz im Kopf der auf einem Public Key als einzig bekannter Hinweis auf den Empfänger der jeweiligen Nachricht gegeben ist.

Was mir aber noch Kopfzerbrechen bereitet ist folgendes:

BenBE hat folgendes geschrieben :

Jegliche hinterlassenen Spuren können daher, wenn sie zugeordnet werden, gegen den Nutzer ausgelegt werden.

Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben?

mfg

LexXis hat folgendes geschrieben :

...Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben? mfg

Davon ist auszugehen!

BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar.
Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt.

LexXis hat folgendes geschrieben :

Hm.. Interessante Frage Wie würdest du "Identität" definieren? Hatte gerade einen Ansatz im Kopf der auf einem Public Key als einzig bekannter Hinweis auf den Empfänger der jeweiligen Nachricht gegeben ist. Was mir aber noch Kopfzerbrechen bereitet ist folgendes: BenBE hat folgendes geschrieben : Jegliche hinterlassenen Spuren können daher, wenn sie zugeordnet werden, gegen den Nutzer ausgelegt werden. Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben? mfg

Von dieser Strenge ist durchaus auszugehen. Wie hathor ja schreibt: **** Vereinigungen usw.

Für den Einstieg können wir aber gerne auch mit vereinfachten Anforderungen beginnen.

hathor hat folgendes geschrieben :

LexXis hat folgendes geschrieben : ...Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben? mfg Davon ist auszugehen! BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar. Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt.

Ich sagte ja: Ähnlichkeiten mit real existierenden Staaten sind rein zufällig...

Bliebe aber immer noch der Punkt, wie man in einem überwachten Netz Information erlangen kann, ohne dass jemand, der meine Kommunikation mitschneidet, belastbare Informationen darüber erhält, dass ich z.B. zu einem Darknet Kontakt aufnehme. Die Side-Channel-Angriffe sind in solch einer Umgebung das gefährlichere ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Puh, haarige Angelegenheit
Um das Ganze etwas in Gang zu halten poste ich hier einfach mal meine erste Idee und die Lücken, die sich noch in ihr befinden. Evtl kann ja jemand ergänzen, um diese zu schließen.

Grundsätzliches:

1. Gegeben ist eine Menge von Knoten, die sich untereinander kennen (IP-basiert).
   
2. Jeder Teilnehmer besitzt ein asymetrisches Schlüsselpaar
   
3. Versendete Pakete haben eine feste Größe, um diese als Ansatz zur Paketverfolgung / -identifikation auszuschließen.
   
4. Im Paketheader befindet sich ein TTL-Feld, welches vor jeder Übertragung um 1 reduziert wird. Ist TTL bei 0 wird das Paket verworfen.
   
5. Will ein Knoten einem anderen Daten senden, so fordert er davor von diesem einen anderen, zufälligen Schlüssel zur asymetrischen Verschlüsselung an.
   

Zur Kommunikation zwischen zwei Konten: Alice möchte eine Nachricht an Bob versenden

1. Alice ist im Besitz von Bobs öffentlichem Schlüssel und
   
2. verschlüsselt damit die Nachricht.
   
3. Von seinen bekannten Knoten Charlie, Eve und Florence fordert er jeweils einen temporären Schlüssel an,
   
4. verschlüsselt den Paketheader und Bobs Nachricht damit und
   
5. sendet diese Pakete an die Drei.
   
6. Diese entschlüsseln das Paket mit dem temporären Schlüssel und die Nachricht noch einmal mit ihrem private key.
   
7. Sie stellen fest, dass sie mit der Nachricht nichts anfangen können (diese ist nur für Bob lesbar!) und
   
8. versenden nach dem selben Procedere Header und Nachricht wiederum an all ihre Bekannten.
   

Irgendwann sollte das Paket bei Bob angekommen sein. Dieser kann die Nachricht problemlos entschlüsseln, da er den richtigen private key besitzt. Um jedoch keinen Verdacht aufkommen zu lassen, verschickt er das Paket auch selbst weiter.

Wie bereits erwähnt handelt es sich hierbei nur um einen groben Abriss. Beim Anfordern der temporären Schlüssel ist das System anfällig für MITM-Angriffe, es erfordert massiv Rechenzeit beim ständigen Erstellen selbiger und ist aufgrund des Mangels an Routing höhst ineffizient. Gerade hier liegt jedoch eine der Stärken: Es ist von außen nicht ersichtlich, wer der Empfänger war. Angesichts der drohenden Side-Channel-Attacken verflüchtigt sich dieser Punkt aber auch recht schnell wieder.

hathor hat folgendes geschrieben :

BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar. Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt.

Ich nehme mal an, dass besagter Staat auch was dagegen hat, wenn man offenkundig Datenmüll (=verschlüsselte Daten) durch seine Infrastruktur jagt Von daher wird mein jetziger Ansatz wohl in keinster Weise BenBEs Rahmenbedingungen gerecht.
Aber das Thema ist einfach zu spannend, um nicht dazu beizutragen

BenBE, schwebt dir schon was vor? Wie wäre es mit in Bildern versteckten Daten (Steganographie) in einem Imageboard a la /b/?

mfg

LexXis hat folgendes geschrieben :

hathor hat folgendes geschrieben : BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar. Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt. Ich nehme mal an, dass besagter Staat auch was dagegen hat, wenn man offenkundig Datenmüll (=verschlüsselte Daten) durch seine Infrastruktur jagt Von daher wird mein jetziger Ansatz wohl in keinster Weise BenBEs Rahmenbedingungen gerecht. Aber das Thema ist einfach zu spannend, um nicht dazu beizutragen BenBE, schwebt dir schon was vor? Wie wäre es mit in Bildern versteckten Daten (Steganographie) in einem Imageboard a la /b/? mfg

§ 1984:
Die Picture Sharing Group (PSG) ist verboten. Die Mitgliedschaft wird mit ....bestraft.

LexXis hat folgendes geschrieben :

Puh, haarige Angelegenheit Um das Ganze etwas in Gang zu halten poste ich hier einfach mal meine erste Idee und die Lücken, die sich noch in ihr befinden. Evtl kann ja jemand ergänzen, um diese zu schließen.

Das ist doch immerhin schon mal ein Ansatz; beschreibt aber die Arbeitsweise innerhalb des Netzwerkes nicht ganz. Zum besseren Verständnis, wie man ohne mehr als nötig Overhead zu produzieren Daten senden kann, würde ich einen Blick in Richtung Onion Routing bzw. Garlic Routing werfen. Dazu aber gleich mehr.

LexXis hat folgendes geschrieben :

Grundsätzliches: Gegeben ist eine Menge von Knoten, die sich untereinander kennen (IP-basiert).

Nicht wirklich anonym ...

Beispiel: Bei I2P kennen die Knoten zwar untereinander auch ihre IP, die Kommunikation läuft aber nicht über die IP, sondern über die Knoten-IP. Insbesondere muss dem Absender einer Nachricht nicht bekannt sein, welche IP der Empfänger hat. Dies sollte auch wenn möglich nicht auf direktem Wege über das Netzwerk ermittelbar sein. Man braucht zwar die IP, um einen anderen Knoten zu erreichen, es reicht aber, wenn jeder Knoten eine kurze Liste von Knoten überhaupt kennt (mit deren ID), um mit diesen zu reden.

LexXis hat folgendes geschrieben :

Jeder Teilnehmer besitzt ein asymetrisches Schlüsselpaar

Jeder Teilnehmer besitzt ein asymmetrisches Schlüsselpaar sowie eine Knoten-ID. Beide müssen nichts gemeinsam haben; sollten sogar wenn möglich aus verschiedenen Quelldaten generiert worden sein.

LexXis hat folgendes geschrieben :

Versendete Pakete haben eine feste Größe, um diese als Ansatz zur Paketverfolgung / -identifikation auszuschließen.

Der Satz erscheint mir grad unlogisch, da eine feste Paketgröße ein Identifikationsmerkmal der Pakete wäre. Viel mehr würde ich vorschlagen, eine Mischung aus OTR und dem RC4-160-Enc-Protokoll von Vuze zu sprechen: OTR garantiert die (Weak) Deniability, während das Protokoll von Vuze dafür sorgt, dass die Daten für DPI "unsichtbar" werden. Auch hierzu sollte man aber ggf. später noch mehr erklären.

LexXis hat folgendes geschrieben :

Im Paketheader befindet sich ein TTL-Feld, welches vor jeder Übertragung um 1 reduziert wird. Ist TTL bei 0 wird das Paket verworfen.

Vgl. mit I2P: TTL wird für Ausgangswert nur in X% der Fälle dekrementiert, um zu verhindern, dass der erste Knoten sich sicher sein kann, wer die Quelle des Pakets ist.

LexXis hat folgendes geschrieben :

Will ein Knoten einem anderen Daten senden, so fordert er davor von diesem einen anderen, zufälligen Schlüssel zur asymetrischen Verschlüsselung an.

Siehe Key Exchange Protokoll von OTR. In einem solchen, anonymen System sollte die Lebensdauer von Schlüsseln möglichst kurz sein.

LexXis hat folgendes geschrieben :

Zur Kommunikation zwischen zwei Konten: Alice möchte eine Nachricht an Bob versenden Alice ist im Besitz von Bobs öffentlichem Schlüssel und

k, nehmen wir jetzt mal an, Möglichkeiten, wie Alice da ran kommt, könnten später diskutiert werden.

LexXis hat folgendes geschrieben :

verschlüsselt damit die Nachricht.

Bitte bei OTR in den Design Goals nachlesen, warum DAS eine ganz schlechte Idee ist.
Besser: Alice handelt mit Bob eine Kommunikationssitzung über ein OTR-ähnliches Protokoll aus. Dabei wird (im Gegensatz zu OTR) ein asymmetrischer Schlüssel generiert (von dem Alice UND Bob beide Teile kennen*)

*Ja, das mein ich ernst Grund: OTR nutzt AES128-CTR für die Verschlüsslung, was durchaus reicht, ABER da es symmetrisch verschlüsselt ist, sofort bei Bekanntgabe des Symmetrischen Schlüssels den Plaintext verriete. Mit einem Assymetrischen Schlüsselpaar kann Florence ein gefälschtes Transcript anfertigen, was vollkommen gültig ist UND korrekt validiert werden kann (vgl. OTR).

LexXis hat folgendes geschrieben :

Von seinen bekannten Knoten Charlie, Eve und Florence fordert er jeweils einen temporären Schlüssel an, verschlüsselt den Paketheader und Bobs Nachricht damit und sendet diese Pakete an die Drei.

Vorschlag: Hier machen wir Garlic Routing: Er leitet generell sowieso Pakete weiter und streut sein Paket nur in den Datenstrom mit ein.

LexXis hat folgendes geschrieben :

Diese entschlüsseln das Paket mit dem temporären Schlüssel und die Nachricht noch einmal mit ihrem private key.

Garlic Routing, vgl. I2P.

LexXis hat folgendes geschrieben :

Sie stellen fest, dass sie mit der Nachricht nichts anfangen können (diese ist nur für Bob lesbar!) und

Und haben Bandbreite verschwendet

LexXis hat folgendes geschrieben :

versenden nach dem selben Procedere Header und Nachricht wiederum an all ihre Bekannten.

Da ist Garlic Routing wirklich effizienter Zumal man bei Garlic Routing auch Chaffing and Winnowing einsetzen könnte.

LexXis hat folgendes geschrieben :

Irgendwann sollte das Paket bei Bob angekommen sein. Dieser kann die Nachricht problemlos entschlüsseln, da er den richtigen private key besitzt. Um jedoch keinen Verdacht aufkommen zu lassen, verschickt er das Paket auch selbst weiter.

Entfällt IMHO bei Garlic Routing, auch wenn man es einbauen könnte - wäre aber Traffic-Verschwendung.

LexXis hat folgendes geschrieben :

Wie bereits erwähnt handelt es sich hierbei nur um einen groben Abriss. Beim Anfordern der temporären Schlüssel ist das System anfällig für MITM-Angriffe, es erfordert massiv Rechenzeit beim ständigen Erstellen selbiger und ist aufgrund des Mangels an Routing höhst ineffizient.

Jap. Wurde bei I2P bereits besser gelöst, weshalb ich das für Netz-Interne Kommunikation bevorzugen würde.

LexXis hat folgendes geschrieben :

Gerade hier liegt jedoch eine der Stärken: Es ist von außen nicht ersichtlich, wer der Empfänger war.

Doch: Einer der vier, von denen Alice einen temporären Key angefordert hat. Und das ist, dank Paket-Vorratsdatenspeicherung durchaus nachvollziehbar.

LexXis hat folgendes geschrieben :

Angesichts der drohenden Side-Channel-Attacken verflüchtigt sich dieser Punkt aber auch recht schnell wieder.

Erklärung zu diesem Punkt bitte?

LexXis hat folgendes geschrieben :

hathor hat folgendes geschrieben : BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar. Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt. Ich nehme mal an, dass besagter Staat auch was dagegen hat, wenn man offenkundig Datenmüll (=verschlüsselte Daten) durch seine Infrastruktur jagt Von daher wird mein jetziger Ansatz wohl in keinster Weise BenBEs Rahmenbedingungen gerecht. Aber das Thema ist einfach zu spannend, um nicht dazu beizutragen

Och, da kann der Staat leider nicht viel machen, da:
1. Das Verbieten von Kryptographie nichts bringt (vgl. Chaffing and Winnowing)
2. Viele kryptographische Primitiva (z.B. Hashes, HMACs) essentiell für das Funktionieren der Infrastruktur sind.
ABER: Er kann einschränken, WELCHE kryptographischen Primitiva genutzt werden dürften (vgl. Frankreich bis Mitte der 1990er.

LexXis hat folgendes geschrieben :

BenBE, schwebt dir schon was vor? Wie wäre es mit in Bildern versteckten Daten (Steganographie) in einem Imageboard a la /b/?

Selbst wenn /b/ eine Möglichkeit darstellen würde, würde Steganographie hier nicht viel bringen (vgl. oben: Der Source ist offen).

Wem die beiden Begriffe Onion Routing und Garlic Routing nix sagen:
Onion Routing: Alice verschlüsselt Datenpaket an Bob der Reihe nach an Bob, Charlie, Dave, Eve, Florence, Trent, Vera und sendet es an Vera. Vera an Trend, usw. U.a. bei Tor eingesetzt (Daher der Name )

Garlic Routing: Datenpaket an Bob ist mit einem Session-Schlüssel verschlüsselt. Zusätzlich wird Point-to-Point zwischen Charlie, Dave, Eve, Florence, Trend und Vera der jeweilige Hop mit dem Next-Hop-Schlüssel gesichert. Bei jedem Hop werden aber ANDERE Datenpakete (oder Fragmente) mit Bobs Paket zusammen in einer Hülle gepackt. (Bei I2P eingesetzt).

Ach ja, zum Thema Vuze-Protokoll und Verschleierung, eine Grobfassung:
Vuze nutzt für die Aushandlung eines Session-Keys ein modifiziertes DH-Kex, bei dem beide Parteien am Anfang der Verbindung eine vorgegebene Menge an "Zufallsdaten" senden, gefolgt von einer zufälligen Menge Datenmüll, der ignoriert wird. Da beide Parteien ein "Shared Secret" haben (meist der Torrent-Hash), können beide nach der Übertragung des Datenmülls Problemlos wieder in den Datenstrom der Gegenseite synchronisieren. Problem bei Vuze ist dabei, dass das Verfahren für MITM anfällig ist. Hier bessert aber OTR mit seinem Protokoll recht gut nach, da bei OTR anhand der Schlüssel zusätzlich Authentifiziert wird. Da empfehl ich für Details einfach mal einen Blick in die beiden Specs, die lesen sich beide recht angenehm (im Vgl. zu anderen crypt. Doc).

Um die Frage dieses Threads scheinen wir uns aber irgendwie noch zu drücken

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ich gehe davon aus, dass ein autoritärer Staat nur den Datenverkehr zulässt, den er kontrollieren, d.h. "verstehen" kann. Alles Andere wird herausgefiltert.

hathor hat folgendes geschrieben :

Ich gehe davon aus, dass ein autoritärer Staat nur den Datenverkehr zulässt, den er kontrollieren, d.h. "verstehen" kann. Alles Andere wird herausgefiltert.

Tor sieht nach außen wie SSL aus, ist's aber nicht Nur so BTW.

Wenn man das aber ins Extreme treibt: Ja ^^

Ich geh aber für diese Frage mal davon aus, dass wir ein neutrales Netz haben, in dem jedoch alle Kommunikation protokolliert wird. Wenn man dafür nämlich eine Lösung hat, ist die Folgerung für restriktivere Systeme nämlich relativ einfach vollziehbar.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Was verstehst du genau unter Anonymität und gleichzeitiger Authentizität der Teilnehmer? Welche Eigenschaften SOLLEN geschaffen werden?

Grundsätzlich sind OTPs bzw Stromchiffren und MACs dazu in er Lage abstreitbar Daten zu verschlüsseln und deren Autentizität und Integrität zu schützen. DH in Verbindung mit Signaturen schaffen am Protokollbeginn die nötigen symmetrischen Schlüssel und ein authentisches Gespräch. Für eine anonyme Kommunikation kann man zudem noch Coverd-Channels nutzen.

Ich finde das Thema sehr interessant und habe viele Ideen und würde daher gerne weiter mit diskutieren?!

Sirke hat folgendes geschrieben :

Was verstehst du genau unter Anonymität und gleichzeitiger Authentizität der Teilnehmer? Welche Eigenschaften SOLLEN geschaffen werden?

Anonymität: Es ist nicht (gezielt) möglich, eine Zuordnung von Kommunikations-IDs zu realen (Side-Channel-)Daten herzustellen
Authentizität: Es ist sichergestellt, dass wenn Alice mit Bob reden möchte, beide Parteien feststellen können, dass sie mit dem jeweils anderen reden, OHNE dies gegenüber einem anderen beweisen zu können.

Sirke hat folgendes geschrieben :

Grundsätzlich sind OTPs bzw Stromchiffren und MACs dazu in er Lage abstreitbar Daten zu verschlüsseln und deren Autentizität und Integrität zu schützen.

ACK.

Sirke hat folgendes geschrieben :

DH in Verbindung mit Signaturen schaffen am Protokollbeginn die nötigen symmetrischen Schlüssel und ein authentisches Gespräch.

Wobei man bei Signaturen vorsichtig sein sollte bzgl. Abstreitbarkeit, da Signaturen u.U. auch die Identität nicht nur für den Empfänger, sondern für alle Beteiligten offenbaren. HMACs dürften da hier besser sein.

Sirke hat folgendes geschrieben :

Für eine anonyme Kommunikation kann man zudem noch Coverd-Channels nutzen.

Details?

Sirke hat folgendes geschrieben :

Ich finde das Thema sehr interessant und habe viele Ideen und würde daher gerne weiter mit diskutieren?!

Dann immer zu

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

Anonymität: Es ist nicht (gezielt) möglich, eine Zuordnung von Kommunikations-IDs zu realen (Side-Channel-)Daten herzustellen

Okay, dies bedeutet aber, dass man einen Anonymisierungsdienst benötigt, da man sonst (1) die IP-Adressen zuordnen kann und (2) sogar die Kommunikation beider oder mehrere Adressen verbinden kann. Generell ist die Verlinkbarkeit die größte Hürde, weil nur Redundanz dies in einem größeren Maß verhindern kann. Eine mögliche Lösung wäre, dass jede Partei n Pakete mit verschiedenen IDs an einen zentralen Punkt sendet und dort jede Partei k Pakete abholt, wovon nur ein Paket das gewünscht ist und alle anderen Pakete nur zufälliger Datenmüll. Wobei auch dies nicht das Problem vollständig löst, weil Onlinezeiten und Abrufzeiten eine Verbindung ermöglichen.

BenBE hat folgendes geschrieben :

Authentizität: Es ist sichergestellt, dass wenn Alice mit Bob reden möchte, beide Parteien feststellen können, dass sie mit dem jeweils anderen reden, OHNE dies gegenüber einem anderen beweisen zu können.

Diesen Punkt habe ich schon oft mit Komilitonen diskutiert, weil wenn beide einander beweisen, dass sie miteinander kommunizieren, kann jede Partei diesen Beweis anderen vorlegen und damit dies auch anderen beweisen. Dieses Problem besteht nämlich bei der Voraussetzung "KÖNNEN", weil dies einen unehrlichen Kommunnikationspartner als Möglichkeit enthält, der alle seine geheimen Schlüssel offen legt.

BenBE hat folgendes geschrieben :

Wobei man bei Signaturen vorsichtig sein sollte bzgl. Abstreitbarkeit, da Signaturen u.U. auch die Identität nicht nur für den Empfänger, sondern für alle Beteiligten offenbaren. HMACs dürften da hier besser sein.

Auf jeden Fall sind symmetrische Verfahren besser geeignet, weil hierbei die andere Partei immer eine Fälschung erstellen kann und somit eine Abstreitbarkeit gegeben bleibt. Gleichzeitig muss jedoch jede Partei mit allen Kommunikationspartnern einen symm. Schlüssel teilen, was ein großen Problem bereitet. Daher bräuchte man eher asymm. Krypto.

ODER: Gibt es eine Möglichkeit einen DH Schlüsselaustausch in irgend einer Weise abzusichern OHNE dass ein Langzeitschlüssel benötigt wird? Die Folge wäre jedoch wieder, dass man keine Zusicherung schaffen kann, mit wem man Kommuniziert.

BenBE hat folgendes geschrieben :

Details?

Coverd-Channels sind ja grundsätzlich Kanäle, welche in andere Kanäle eingebettet werden. So soll/wird bei Online-Rollenspielen in den Nutzdaten vertrauliche/geheime Informationen versendet, indem Steganogrphie zum Einsatz kommt. Hierbei könnte man ähnliches machen:
Eine Partei sendet ein k-fach verschlüsseltes Paket (mit k verschiedenen öffentlichen Schlüsseln) an eine Partei, welche die äußere Hülle abnimmt und dort die Infos zum Weitersenden findet. In irgendeiner "Schale" befindet sich dann ein eingebettetes Paket, wovon die Partei weiß und diese extrahiert und die "Schalen" weitersendet:
Mit E(PKi,m) sein eine Verschlüsselung mit einem öffentlichen Schlüssel von i der Nachricht m gemeint und + bezeichnet eine Verknüpfung irgendeiner Form:



EDIT: Folgenden Kreis könnte man sich in der Schalen-Verkapselung vorstellen, indem das Paket wieder beim Absender X ankommt. In weiteren Kreisläufen kann dann Y in diese Pakete seine Nachricht an X anfügen:

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Anonymität: Es ist nicht (gezielt) möglich, eine Zuordnung von Kommunikations-IDs zu realen (Side-Channel-)Daten herzustellen Okay, dies bedeutet aber, dass man einen Anonymisierungsdienst benötigt, da man sonst (1) die IP-Adressen zuordnen kann und (2) sogar die Kommunikation beider oder mehrere Adressen verbinden kann. Generell ist die Verlinkbarkeit die größte Hürde, weil nur Redundanz dies in einem größeren Maß verhindern kann. Eine mögliche Lösung wäre, dass jede Partei n Pakete mit verschiedenen IDs an einen zentralen Punkt sendet und dort jede Partei k Pakete abholt, wovon nur ein Paket das gewünscht ist und alle anderen Pakete nur zufälliger Datenmüll. Wobei auch dies nicht das Problem vollständig löst, weil Onlinezeiten und Abrufzeiten eine Verbindung ermöglichen.

Garlic Routing. Angriff dabei sind Vloume\Timing-Attacken, aber das kann man recht gut eingrenzen.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Authentizität: Es ist sichergestellt, dass wenn Alice mit Bob reden möchte, beide Parteien feststellen können, dass sie mit dem jeweils anderen reden, OHNE dies gegenüber einem anderen beweisen zu können. Diesen Punkt habe ich schon oft mit Komilitonen diskutiert, weil wenn beide einander beweisen, dass sie miteinander kommunizieren, kann jede Partei diesen Beweis anderen vorlegen und damit dies auch anderen beweisen. Dieses Problem besteht nämlich bei der Voraussetzung "KÖNNEN", weil dies einen unehrlichen Kommunnikationspartner als Möglichkeit enthält, der alle seine geheimen Schlüssel offen legt.

Authentifizierung nicht mit einer Signatur, sondern mit einem HMAC. Damit kann man die Authentizität zwar nachweisen, aber nicht beweisen, weil man selber ja den Schlüssel auch hat und daher das Paket fälschen könnte. Vgl. Auth bei OTR.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Wobei man bei Signaturen vorsichtig sein sollte bzgl. Abstreitbarkeit, da Signaturen u.U. auch die Identität nicht nur für den Empfänger, sondern für alle Beteiligten offenbaren. HMACs dürften da hier besser sein. Auf jeden Fall sind symmetrische Verfahren besser geeignet, weil hierbei die andere Partei immer eine Fälschung erstellen kann und somit eine Abstreitbarkeit gegeben bleibt. Gleichzeitig muss jedoch jede Partei mit allen Kommunikationspartnern einen symm. Schlüssel teilen, was ein großen Problem bereitet. Daher bräuchte man eher asymm. Krypto.

Bzw. eine Mischung daraus. Oft wird zur Lösung dieses Problems mit vielen kleinen Session-Schlüsseln gearbeitet, was die Arbeit stark erleichtert.

Sirke hat folgendes geschrieben :

ODER: Gibt es eine Möglichkeit einen DH Schlüsselaustausch in irgend einer Weise abzusichern OHNE dass ein Langzeitschlüssel benötigt wird? Die Folge wäre jedoch wieder, dass man keine Zusicherung schaffen kann, mit wem man Kommuniziert.

Spannende Frage. Soweit ich das bisher gesehen hab: Jain. OTR authentifiziert seinen DH-like Kex mit einem Public Key, ohne dass dieser für Dritte beweisbar ist. Dürfte also da durchaus Möglichkeiten geben.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Details? Coverd-Channels sind ja grundsätzlich Kanäle, welche in andere Kanäle eingebettet werden. So soll/wird bei Online-Rollenspielen in den Nutzdaten vertrauliche/geheime Informationen versendet, indem Steganogrphie zum Einsatz kommt. Hierbei könnte man ähnliches machen: Eine Partei sendet ein k-fach verschlüsseltes Paket (mit k verschiedenen öffentlichen Schlüsseln) an eine Partei, welche die äußere Hülle abnimmt und dort die Infos zum Weitersenden findet. In irgendeiner "Schale" befindet sich dann ein eingebettetes Paket, wovon die Partei weiß und diese extrahiert und die "Schalen" weitersendet: Mit E(PKi,m) sein eine Verschlüsselung mit einem öffentlichen Schlüssel von i der Nachricht m gemeint und + bezeichnet eine Verknüpfung irgendeiner Form: markieren Quelltext     1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: E(PK1, E(PK2, E(PK3, E(PK4, E(PK5, E(PK6, m' )  )  )  + m )  )  ) = C 1.) C an 1 senden: D(SK1, C ) = E(PK2, E(PK3, E(PK4, E(PK5, E(PK6, m' )  )  )  + m )  ) = C 2.) C an 2 senden: D(SK2, C ) = E(PK3, E(PK4, E(PK5, E(PK6, m' )  )  )  + m ) = C 3.) C an 3 senden: D(SK3, C ) = E(PK4, E(PK5, E(PK6, m' )  )  )  + m = C -> Er weiß von der Nachricht und kann diese extrahieren: Ex( C ) = m 4.) C an 4 senden: D(SK4, C ) = E(PK5, E(PK6, m' )  ) = C . . .

Das wäre eine Idee, funktioniert im konkreten Fall doch aber nicht, wenn jemand frisch ins Netzwerk joinen möchte?

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Mein Ansinnen ist es nicht, diese interessante Diskussion zu torpedieren, erlaube mir aber, sie als ziemlich akademisch einzustufen.

Es wäre nämlich völlig inkonsequent, daß ein Staat massive Überwachung, Zensur und Repression auf der einen Seite betriebe, jedoch eine kryptische Tarnung in Informationsnetzwerken auf der anderen Seite zuließe.

Nur mal zwei Beispiele: Das sog. Vermummungsverbot in der BRD (wo sonst noch?) und das ernsthafte Ansinnen der USA, Computer ohne Palladium zu verbieten, dienen nur dazu, den Ermittlungsaufwand zu minimieren und die Ermittlungswahrscheinlichkeit zu maximieren. Gut, der sog. Palladiumcomputer war vor allem erst einmal kommerziellen Bedürfnissen gechuldet, hätte aber auch die totale Überwachung(smöglichkeit) nach sich gezogen. Zum Glück hat sich das erst einmal wieder zerschlagen.

Die Vorratsdatenspeicherung zeigt doch klar, wohin der Weg geht: Zur totalen Überwachung, die Orwell literarisch prognostizierte - eine total(itär)e Diktatur wird die Spätfolge, die finale Konsequenz dieser Entwicklung und dieses Begehren sein.

Die Stasi 2.0, die hierzulande längst gang und gäbe ist (und mit ihren technischen Möglichkeiten die Stasi 1.0 in den Schatten stellt und diese im nachhinein neidisch werden läßt), hat ja ihr Haupteinsatzfeld längst im Bereich der elektronischen (Massen-)Kommunikation. Man wird sich doch selbst den Sitzast nicht absägen...?!

BenBE hat folgendes geschrieben :

Das wäre eine Idee, funktioniert im konkreten Fall doch aber nicht, wenn jemand frisch ins Netzwerk joinen möchte?

Auf jeden Fall nicht ohne großen Overhead! Entweder man hat IMMER einen vollständigen Ring um alle teilnehmenden Parteien, was jedoch dazu führen kann, dass die Wege und Zeiten sehr lang werden.

Eine andere Lösung wären viele kleine Ringe: Alice hat einen Ring mit n (vllt so um die 10) Parteien und kommuniziert in diesem Ring mit Bob. Carol die deren Kommunikation beitreten möchte bildet nun einen Ring mit Bob und/oder Alice und einer von beiden dient als Verteiler der Teilnehmer in seinem Ring. Eine Verbesserung wäre evtl eine Veröffentlichung alle bestehenden Ringe, sodass Carol einen Ring über mehrere Parteien in dem Ring aufbauen kann, sodass ein Schnittpunkt nicht ermittelt werden kann.

Auch könnte man alle Ringe über einen zentralen Dienst laufen lassen, sodass eben dier Verteiler immer der selbe ist. Leider hat man dann wieder den Single-Point-of-Failure. Für diesen Fall kann aber immernoch eine Notfalllösung mit vielen kleinen Ringen als Ersatz folgen!

Das Problem hinter einer solchen Struktur ist es auszuschließen, dass Verbindungen mit Hilfe von Schnittpunkten der Ringe o.ä. erkannt werden können.


EDIT:
@Delphi-Laie: Klar ist diese Frage rein theoretisch und hätte in vielen Fällen durch die Krypto Probleme, aber dann könnte man das ganze von einer Massangerstruktur zu einer Forenstuktur verändern und dann mit Steganographi die gesamte Kommunikation im Verborgenen halten! Dies schafft nur die Grundlage falls das Verborgene gefunden wird keinen Grund für einen Beweis zu schaffen! ... aber um Rechtslagen zu verwendeter Software geht es hierbei nicht, sondern um Möglichkeiten durchzuspielen.

Ich denke mal, die Möglichkeiten für die Kommunikation innerhalb des Netzwerkes sind eigentlich eher sekundär, da es hier bereits (Speziell für geschlossene Netzwerke / Darknets) recht gute Lösungen gibt. Klar, man kann hier mit verschiedenen Teilnetzen operieren, aber praktisch ist das nur bedingt.

Zumal: Nehmen wir einmal die Authentifizierung. Reicht es nicht, wenn man für einen Schlüssel folgendes weiß:

Festlegung:
- Eine Identität besteht aus einem key (asymm.), einer ID (Hash)
- Zu einer Identität können 0 bis * Locations zugeordnet sein (Multihomed-Systeme z.B., aber das ist hier unwichtig)
- Die ID einer Identität ist HMAC, den jeder Node für sich beliebig ändern kann, solange er die history seiner früheren Knoten-IDs reproduzieren kann
- Zur Bestimmung der Identität der Gegenstelle werden Zero Knowledge-Proofs verwendet, die basierend auf privaten Informationen des Empfängers die Identität (ausschließlich für die Kommunikationspartner) offenlegen können.

Wenn nun Alice mit Bob reden möchte, kann Alice ALLE bisherigen IDs von Bob verwenden, und dieser kann sich Authentifizieren, indem er nach einem Key-Exchange-Verfahren und einem Festlegungs-Verfahren (Bob muss vor der Bekanntgabe der neuen ID, diese an Alice unveränderbar bekanntgeben) Alice beweist, dass er Informationen hat, mit der er neue (Sitzungs-)Schlüssel aus seinem Private Key erzeugen kann.

@Sirke: Ein Ring ist nicht wirklich dezentral und zudem skaliert das nicht P2P allerdings schon

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Die idee klingt nicht schlecht, aber wenn wir schon asymm Krypto nutzen und mit einem HMAC individuelle IDs generieren, dann kann man doch eher folgende Variante nehmen:

Man definiere eine Primzahl p und zufällig x aus Z_p*, sowie g und h Generatoren aus Z_p*. Der geheime Schlüssel ist dann x und der öffentliche y = g^x * h^r mod p, wobei r zufällig aus Z_p*. Hierbei kann jedes r einen neuen öffentlichen Schlüssel erzeugen, welcher gleichzeitig die ID ist bzw der gehasht die ID ist.

Mittels deiner Idee des Zero-Knowlege Proofs kann der Besitzer die Kenntnis von x und r beweisen und damit die Zugehörigkeit zu diesem Schlüssel. Gleichzeitig kann man mit diesen Werten einen DH absichern, indem man die DH Werte signiert. Evtl kann man auch ohne DH aus den beiden öffentlichen Schlüsseln einen SessionKey berechnen...

Sirke hat folgendes geschrieben :

Die idee klingt nicht schlecht, aber wenn wir schon asymm Krypto nutzen und mit einem HMAC individuelle IDs generieren, dann kann man doch eher folgende Variante nehmen: Man definiere eine Primzahl p und zufällig x aus Z_p*, sowie g und h Generatoren aus Z_p*. Der geheime Schlüssel ist dann x und der öffentliche y = g^x * h^r mod p, wobei r zufällig aus Z_p*.

Das sieht mir jetzt aber verdammt nach ECC aus Ginge sicherlich auch, ist im Endeffekt aber doch sicherlich eher ein reines Implementationsdetail

Sirke hat folgendes geschrieben :

Hierbei kann jedes r einen neuen öffentlichen Schlüssel erzeugen, welcher gleichzeitig die ID ist bzw der gehasht die ID ist.

Hmmm, klingt interessant. Ich sehe: Im Netzwerk kommunizieren wäre schon mal erledigt

Sirke hat folgendes geschrieben :

Mittels deiner Idee des Zero-Knowlege Proofs kann der Besitzer die Kenntnis von x und r beweisen und damit die Zugehörigkeit zu diesem Schlüssel. Gleichzeitig kann man mit diesen Werten einen DH absichern, indem man die DH Werte signiert. Evtl kann man auch ohne DH aus den beiden öffentlichen Schlüsseln einen SessionKey berechnen...

Der DH Kex sollte auf vollständig zufälligen Daten basieren und erstmal unabhängig von der Auth sein. Wichtig ist doch, dass die Identität für keinen Außenstehenden nachprüfbar wird. Und da haben wir ja mehr oder weniger schon die Werkzeuge.

Gehen wir jetzt aber wirklich mal zu dem Punkt, dass Alice, Bob und Charlie untereinander reden können.
1. Was muss Dave von Alice, Bob ODER Charlie in Erfahrung bringen, um einen der anderen Leute kontaktieren zu können? (Wir gehen von dynamischen IPs aus)
2. Wie könnte er diese Daten "automatisierbar" erhalten, ohne dass Verdacht entsteht? (Einen Zettel von Trent oder Vera zu erhalten ist nicht automatisiert, auch wenn es gehen würde )
3. WIE sollte die erste Kontaktaufnahme gestaltet werden?

Zu 1. vielleicht eine Idee, auch wenn die recht unpraktikabel ist:
Gegeben Dave hat die ID von Alice, sowie eine Subnetz-Angabe (von z.B. einem /16, so könnte Dave versuchen, für alle IPs auf einem, von der IP+ID abhängigen Portnummer ein UDP-Paket zu senden, in dem eine zufällige Menge an Daten enthalten ist (warum zufällige Menge, siehe oben; Bedeutung: Daten sind Teil der ersten Nachricht eines DH-Kex). Antwort wäre dann wiederum eine Zufällige Menge von Daten (2. Schritt). Danach sendet jede Seite eine Zufällige Menge an Daten noch nach, bis
1. die für den DH-Kex nötige Datenmenge da ist
2. n zusätzliche Bytes übertragen wurden.
Dabei gilt: Das Paket, was die Mindest-Datenmenge der ersten beiden Schritte abschließt, beendet den Schritt für den jeweiligen Teilnehmer. Danach wird ganz normal weiter geredet (ähnlich Vuze oder OTR).

Dieses Vorgehen ist in der Form aber, trotz der Shared Knowledge (die ID von Alice) doch aber sicherlich nicht für 3. akzeptabel? Angriffe?

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Befinden wir uns bereits in einem anonymen o.ä. Netzwerk oder soll es grundsätzlich auch übers WAN möglich sein?


Eine Möglichkeit die mir einfällt wäre folgende - wobei ich auch die Schwachpunkte schon kenne:

1. Alice kontaktiert Bob und teilt ihm über irgendeinen Kanal seine ID mit, falls Bob mal mit Alice reden möchte! - Ist dies noch erwünscht oder könnte dies schon Probleme mit sich bringen?
   
2. Bob möchte Alice kontaktiere und Broadcastet die ID ins Netz, was entweder ein klassisches Broadcast sein kann (was natürlich nur in kleinen Subnetzten möglich ist) oder ein Rundruf über alle bekannten Kontakte alle im Netz teilnehmenden Personen.
   
3. Alice kontaktiert daraufhin Bob und beweißt ihm dass ihm wirklich die ID gehört.
   
4. Danach DH Key-Exchange und Kommunikation...

Evtl könnte man auch überlegen ob es möglich ist an jeden eine andere zufällige ID zu verteilen und es polynominell prüfbar ist, ob diese ID zum eigenen Schlüssel gehört => Viele verschiedene IDs der selben Partei!

An sich müssen wir hierbei noch klären, was genau die Ziele sind:

• Abstreibare, Vertrauliche, Authentische und Integre Kommunikation von zwei Parteien!
• Darf bekannt sein wer mit wem kommuniziert hat oder nur dass zwei Parteien miteinander kommuniziert haben?
• Forward-Secrecy! (wird durch DH ja erreicht)
• ...weitere Ziele?

Sirke hat folgendes geschrieben :

Befinden wir uns bereits in einem anonymen o.ä. Netzwerk oder soll es grundsätzlich auch übers WAN möglich sein? Eine Möglichkeit die mir einfällt wäre folgende - wobei ich auch die Schwachpunkte schon kenne: Alice kontaktiert Bob und teilt ihm über irgendeinen Kanal seine ID mit, falls Bob mal mit Alice reden möchte! - Ist dies noch erwünscht oder könnte dies schon Probleme mit sich bringen?

Könnte man ggf. beide Fälle betrachten. Einfacher dürfte aber sein, wenn dies nicht als strafbar betrachtet wird, obgleich das eigentlich schon sehr stark eine Mitgliedschaft vermuten lässt.

Sirke hat folgendes geschrieben :

Bob möchte Alice kontaktiere und Broadcastet die ID ins Netz, was entweder ein klassisches Broadcast sein kann (was natürlich nur in kleinen Subnetzten möglich ist) oder ein Rundruf über alle bekannten Kontakte alle im Netz teilnehmenden Personen.

Spätestens hier dürfte Traffic entstehen, der suspekt erscheinen könnte ...

Sirke hat folgendes geschrieben :

Alice kontaktiert daraufhin Bob und beweißt ihm dass ihm wirklich die ID gehört.

k, ACK.

Sirke hat folgendes geschrieben :

Danach DH Key-Exchange und Kommunikation... Evtl könnte man auch überlegen ob es möglich ist an jeden eine andere zufällige ID zu verteilen und es polynominell prüfbar ist, ob diese ID zum eigenen Schlüssel gehört => Viele verschiedene IDs der selben Partei!

So in der Form ECC ... Durchaus vorstellbar.

Sirke hat folgendes geschrieben :

An sich müssen wir hierbei noch klären, was genau die Ziele sind: Abstreibare, Vertrauliche, Authentische und Integre Kommunikation von zwei Parteien! Darf bekannt sein wer mit wem kommuniziert hat oder nur dass zwei Parteien miteinander kommuniziert haben? Forward-Secrecy! (wird durch DH ja erreicht) ...weitere Ziele?

Jain. Abstreitbar, ja. Genauso Vertraulich, Authentisch (für die Kommunikationspartner - UND NUR für diese), Integre, Fälschbar (vgl. OTR).
Wer mit wem kommuniziert hat, darf nur für die beteiligten beiden Parteien ersichtlich sein, darf/sollte also für Relay-Knoten nicht ersichtlich sein.
Ziel ist auch Forward Secrecy, jap.

Weitere Ziele fallen mir jetzt grad nicht ein, sind aber glaube auch erstmal nicht zwingend notwenidg - ist ja schon so schwer genug, sowas unter diesen Maßgaben umzusetzen

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.