BenBE hat folgendes geschrieben :

Spätestens hier dürfte Traffic entstehen, der suspekt erscheinen könnte ... (...) 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.

In meinen Augen liegt hier das größte Problem! Die übertragenen Pakete müssen Informationen transportieren und gleichzeitig dürfen sie keine suspekten Strukturenaufweisen.
Aus diesem Grund müsste man bekannte Protokolle wie HTTP, POP oder SMTP nutzen: Sofern SSL/TLS nicht eingeschränkt sind, kann man die zufällige Struktur dieser Pakete nutzen um Daten darin zu kapseln. Sollte SSL/TLS jedoch eingeschränkt sein, muss man die Daten in der gernellen Struktur der Protokolle kapseln. Dann stehen als Fake Webserver, Mailserver und Webservices zur Verfügung, welche Implementiert werden und korrekt reagieren müssen.

Die erwähnten Relay-Knoten sind als kompromittiert bzw überwacht anzusehen?

BenBE hat folgendes geschrieben :

Jain. Abstreitbar, ja. Genauso Vertraulich, Authentisch (für die Kommunikationspartner - UND NUR für diese), Integre, Fälschbar (vgl. OTR).

Diese Punkte wurden ja schon geklärt: AES-CTR dessen SessionKey geheim bleibt und MACs deren SessionKeys offen gelegt werden. Dadurch kann jeder nach dem offen legen der MAC-Keys einen eigenen anderen SessionKey erzeugen und die Nachrichten verändern, sodass sie entschlüsselbar sind und dessen MAC sie selbst erstellen.

BenBE hat folgendes geschrieben :

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.

Dies bedeutet entweder die beiden Parteien kommunizieren offen über einen Dienst welcher nicht auffällt oder deren Kommunikation muss über eine dritte Partei laufen, sodass immer nur eine Partei mit dieser dritten kommuniziert. Diese dritte Partei ist aber dann wieder schwachpunkt des Systems. Daher bleibt nur das Weiterleiten der Pakete über andere Teilnehemer des Systems (vgl TOR), wobei dieses Weiterleiten in öffentlichen Protokollen ohne ersichtliche Inhalte stattfinden muss.

BenBE hat folgendes geschrieben :

Ziel ist auch Forward Secrecy, jap.

Wird durch korrekten DH ja erreicht!

BenBE hat folgendes geschrieben :

So in der Form ECC ... Durchaus vorstellbar.

Denke ECC wäre nicht die sinnvollste Idee, da bisher noch wenig zu Zero-Knowlegde Proofs und anderem im ECC veröffentlicht wurden. Besser wären zur Berechnung prime Gruppen - ja, auch Berechnungen in ECC findet in einer Gruppe statt!

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Spätestens hier dürfte Traffic entstehen, der suspekt erscheinen könnte ... (...) 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. In meinen Augen liegt hier das größte Problem! Die übertragenen Pakete müssen Informationen transportieren und gleichzeitig dürfen sie keine suspekten Strukturenaufweisen. Aus diesem Grund müsste man bekannte Protokolle wie HTTP, POP oder SMTP nutzen: Sofern SSL/TLS nicht eingeschränkt sind, kann man die zufällige Struktur dieser Pakete nutzen um Daten darin zu kapseln. Sollte SSL/TLS jedoch eingeschränkt sein, muss man die Daten in der gernellen Struktur der Protokolle kapseln. Dann stehen als Fake Webserver, Mailserver und Webservices zur Verfügung, welche Implementiert werden und korrekt reagieren müssen.

Jap. So macht es zumindest Tor. Dort wird SSL nachgeahmt ...

Sirke hat folgendes geschrieben :

Die erwähnten Relay-Knoten sind als kompromittiert bzw überwacht anzusehen?

Da das netz anonym ist, sollten wir auch den Trustlevel in seine Teilnehmer möglichst gering halten. Bei Betrachtungen dürfen aber beide Fälle angenommen werden; ggf. mit Erwähnung dessen, was sich ändern würde.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Jain. Abstreitbar, ja. Genauso Vertraulich, Authentisch (für die Kommunikationspartner - UND NUR für diese), Integre, Fälschbar (vgl. OTR). Diese Punkte wurden ja schon geklärt: AES-CTR dessen SessionKey geheim bleibt und MACs deren SessionKeys offen gelegt werden. Dadurch kann jeder nach dem offen legen der MAC-Keys einen eigenen anderen SessionKey erzeugen und die Nachrichten verändern, sodass sie entschlüsselbar sind und dessen MAC sie selbst erstellen.

Wäre die Fälschung dann nicht als solche erkennbar?

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : 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. Dies bedeutet entweder die beiden Parteien kommunizieren offen über einen Dienst welcher nicht auffällt oder deren Kommunikation muss über eine dritte Partei laufen, sodass immer nur eine Partei mit dieser dritten kommuniziert. Diese dritte Partei ist aber dann wieder schwachpunkt des Systems. Daher bleibt nur das Weiterleiten der Pakete über andere Teilnehemer des Systems (vgl TOR), wobei dieses Weiterleiten in öffentlichen Protokollen ohne ersichtliche Inhalte stattfinden muss.

ACK hierbei.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Ziel ist auch Forward Secrecy, jap. Wird durch korrekten DH ja erreicht!

Nicht zwingend DH, aber korrekte Nutzung von kurzlebigen Session-Keys.

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.

Folgendes Szenario wäre auch möglich:
A will B eine Nachricht senden:
A schickt B eine Email im Klartext, die einen ganz normalen, unverfänglichen Text enthält.
Dieser Text enthält aber einen Schlüssel (den ein Dritter nicht sieht!) und einen Link z.B. auf ein Foto, das die eigentliche, geheime Nachricht enthält z.B. einen weiteren Link auf ein verschlüsseltes RAR-File oder ein weiteres Foto mit steganographischer "Nachbearbeitung".
Der unverfängliche Text könnte ganz banal sein und kein Dritter käme auf die Idee, etwas zu suchen...
Der beste Schutz ist der, der nicht wie ein Schutz aussieht!
Vorgestern war ich im Neuen Museum und habe mir nach über dreissig Jahren mal wieder die Nofretete angeschaut. Du wirst es nicht glauben, aber diese schöne Frau ist kein bisschen älter geworden. Wenn Du das Foto sehen willst, hier ist der Link:
lh3.ggpht.com/_wWJnQ...sches+Museum+009.JPG
Der Schlüssel für die geheime Botschaft wäre nun beispielsweise aus der Länge der Wörter zusammenzusetzen, beginnend in einer bestimmten Zeile ("Vorgestern") oder einem bestimmten Wort (Datum=11).
Phantasie ist ein guter Kryptograf.

Das ist korrekt, lässt sich aber nicht wirklich automatisieren, wenn das Verfahren bekannt ist (vgl. oben zwecks Anforderungen). Sicherlich: Wenn ein geheimer Schlüssel eingeht, könnte es wieder machbar wären, das könnte man ggf. ja mal genauer betrachten.

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.

@hathor: Das Einfügen von Daten in ein Bild kann schnell zu Problemen führen. Die einfachste Variante wäre, dass man in jedem Pixel in den Farbwerten das LSB nimmt dieses als Schlüsselbits benutzt. Am Ende erhielte man dann zwei Bilder welche sich durch den Text unterschieden. ABER: Sobald man das veränderte Bild analysiert, fällt der Zufall als Unregelmäßigkeit auf, da Bilder normalerweise weiche Übergange haben und diese dadurch zufällig werden. Weiteres Problem würde die Authentizität bereiten, weil dazu ein "Dialog" von nöten ist!

BenBE hat folgendes geschrieben :

Jap. So macht es zumindest Tor. Dort wird SSL nachgeahmt ...

Bekommt man jedoch Probleme, sobald TLS/SSL verboten würde! Ansonsten wäre dieses Projekt lediglich TOR und OTR zu verbinden.

BenBE hat folgendes geschrieben :

Da das netz anonym ist, sollten wir auch den Trustlevel in seine Teilnehmer möglichst gering halten. Bei Betrachtungen dürfen aber beide Fälle angenommen werden; ggf. mit Erwähnung dessen, was sich ändern würde.

Welches Netz nehmen wir denn an? ...sonst kann man auch dadurch schon Probleme bekommen, dass das Netz nicht möglichist, weil es gefiltert wird!

BenBE hat folgendes geschrieben :

Wäre die Fälschung dann nicht als solche erkennbar?

Nur für die beiden Kommunikationsteilnehmer:
Wir schreiben AES-CTR{K}(m) als die AES Verschlüsselung um Counter-Mode unter dem Schlüssel K ohne beachtung des Counters (weil hier irrelevant) der Nachricht m. Der MAC wird geschrieben als MAC{K}(m) und bedeutet der MAC unter dem Schlüssel K der Nachricht m Zudem berechnet XOR die XOR-Verknüpfung von Byte-Strings. Dann sähe die Kommunikation zwischen Alice (A) und Bob(B) wie folgt aus:
A<->B: n = ( c = AES{Ke}(m), d = MAC{Km}(m) ), mit zuvor ausgetauschten Schlüssel Ke zur Ver/Entschlüsselung und Km zum Berechnen des MACs.
Am Ende der Kommunkation tauschen beide Parteien den MAC-Schlüssel Km im Klartext aus.

Ein Angreifer würde die Nachricht n = (c,d) und den MAC-Schlüssel Km abfangen und könnte nichts mit diesen Werte anfangen, um die orignial Kommuniikation zu erfahren. Bei einer Fälschung würde er folgendes brechnen:
Er erzeugt eine gefälschte Nachricht m' und berechnet AES-CTR{K'}(m') = c' und d' = MAC{Km}(m') und erzeugt dadurch die gefälschte Nachricht n' = (c',d')! Nur die beiden Kommunikationspartner wissen, dass K' nicht Ke ist und die grundlage der Kommunikation ist grundsätzlich, dass dieses Fälschen IMMER möglich ist und keiner sagen kann, ob eine Nachricht n Original oder Fälschung ist.

BenBE hat folgendes geschrieben :

Sirke hat folgendes geschrieben : BenBE hat folgendes geschrieben : Ziel ist auch Forward Secrecy, jap. Wird durch korrekten DH ja erreicht! Nicht zwingend DH, aber korrekte Nutzung von kurzlebigen Session-Keys.

Na dann mal raus, wie du Forward Secrecy OHNE DH erreichen möchtest... Wir dürfen den Session Key dazu NICHT vom Langzeitschlüssel ableiten!


Dann ist das Sinnvollste bisher wohl wirklich das Einbetten in ein bisher bestehendes Protokoll, welches auf jeden Fall legal ist und zur Not SSL/TLS unterstützt, aber auch ohne dieses Feature zufällige Daten enthalten kann. Anschließend kann man an das Protokoll im einzelnen Denken, wie man die Auth und den Key-Ex umsetzt!

Gelöscht

>M@steR< hat folgendes geschrieben :

Hi, Man könnte ja einen Binärcode im Bild speichern, so das z.B. jeder ungrade farbwert einer 0 und jeder grade farbwert einer 1 entspricht. Der geringe unterschied von + - 1 dürfte im Bild nicht auffallen oder?

genau das macht man beim LSB verfahren afaik. Da ändert man nur ein Bit, deswegen wird binär gespeichert. Aber, es gibt analysetools, die erkennen ob ein bild einen Text oder so in den Bytes enthält.

Man korregiere (oder erschlage) mich sollte ich bullshit geredet haben.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

Gelöscht

Sirke hat folgendes geschrieben :

@hathor: Das Einfügen von Daten in ein Bild kann schnell zu Problemen führen. Die einfachste Variante wäre, dass man in jedem Pixel in den Farbwerten das LSB nimmt dieses als Schlüsselbits benutzt. Am Ende erhielte man dann zwei Bilder welche sich durch den Text unterschieden. ABER: Sobald man das veränderte Bild analysiert, fällt der Zufall als Unregelmäßigkeit auf, da Bilder normalerweise weiche Übergange haben und diese dadurch zufällig werden.

Setzt man die richtige Vorschrift zum Verändern der Pixel an (z.B. Daten nur entlang bestehender Kanten ändern) an, kann man diese Auffälligkeit jedoch stark reduzieren. Problematisch dürfte es aber sein, wenn 2 oder mehr Varianteen eines Bildes auftauchen, die zwar gleich aussehen, aber sich in eben diesen Mustern unterscheiden. JEDOCH begründet diese Auffälligkeit nicht zwangsläufig eine Mitgliedschaft, SOFERN die Art der Änderungen nicht auf das Ausgangswerkzeug zurückgeführt werden kann (Wir gehen mal von einem Rechtsstaat aus, bei dem ein Gericht soetwas glaubhaft beweisen muss).

Sirke hat folgendes geschrieben :

Weiteres Problem würde die Authentizität bereiten, weil dazu ein "Dialog" von nöten ist!

Das ist doch aber für das Bild auch nur bedingt nötig, wenn man anhand der darin enthaltenen Informationen zeigen kann, dass der Autor Informationen über das Netzwerk hat, die Mitglieder im Netzwerk zeigen können, und dabei aber von der Nutzung der Nachricht an sich nicht abhängig sind.

Beispiel:
Ich erhalte Nachricht M' aus steganographischem Bild M unter Verwendung von Schlüssel K (z.B. dem Extraktionsverfahren). Die Nachricht M' ist mit Authentifizierungsverfahren (z.B. HMAC) dessen Schlüssel K' mir nicht bekannt ist, den ich aber beim Kommunizieren mit beliebigen Mitgliedern des Netzwerkes erhalten kann. M' enthält eine Art "Knotenverzeichnis" mit nur wenigen Knoten (die an sich nicht direkt ausreichen für eine Verifikation.

Nehme ich nun diese Nachricht her, kontaktiere davon Knoten und führe mit diesen ein Protokoll P aus, über dass ich mir ein "Teilgeheimnis" hole, so kann ich nach einer bestimmten Anzahl an Antworten, die ich durch dieses Protokoll erhalten habe, den Schlüssel berechnen (Group Signatures bzw. Ring Signatures äwren hier z.B. ein Weg).

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Jap. So macht es zumindest Tor. Dort wird SSL nachgeahmt ... Bekommt man jedoch Probleme, sobald TLS/SSL verboten würde! Ansonsten wäre dieses Projekt lediglich TOR und OTR zu verbinden.

I2P mit OTR wäre glaube die bessere Wahl. Onion Routing erzeugt nachvollziehbare Wege. Side Channel Attacke wäre hier mit ner Traffic-Messung möglich (Abwehr dadurch, dass sich das Netz intern anonym über die Traffic-Sitation unterhält und gegensteuert).

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Da das netz anonym ist, sollten wir auch den Trustlevel in seine Teilnehmer möglichst gering halten. Bei Betrachtungen dürfen aber beide Fälle angenommen werden; ggf. mit Erwähnung dessen, was sich ändern würde. Welches Netz nehmen wir denn an? ...sonst kann man auch dadurch schon Probleme bekommen, dass das Netz nicht möglichist, weil es gefiltert wird!

Als Transportnetz nehmen wir ein weitestgehend neutrales Netzwerk an. Dies rührt schon daher, dass keine Filterung perfekt ist und daher solch ein Netz entsprechend gegensteuern können dürfte.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Wäre die Fälschung dann nicht als solche erkennbar? Nur für die beiden Kommunikationsteilnehmer: Wir schreiben AES-CTR{K}(m) als die AES Verschlüsselung um Counter-Mode unter dem Schlüssel K ohne beachtung des Counters (weil hier irrelevant) der Nachricht m. Der MAC wird geschrieben als MAC{K}(m) und bedeutet der MAC unter dem Schlüssel K der Nachricht m Zudem berechnet XOR die XOR-Verknüpfung von Byte-Strings. Dann sähe die Kommunikation zwischen Alice (A) und Bob(B) wie folgt aus: A<->B: n = ( c = AES{Ke}(m), d = MAC{Km}(m) ), mit zuvor ausgetauschten Schlüssel Ke zur Ver/Entschlüsselung und Km zum Berechnen des MACs. Am Ende der Kommunkation tauschen beide Parteien den MAC-Schlüssel Km im Klartext aus. Ein Angreifer würde die Nachricht n = (c,d) und den MAC-Schlüssel Km abfangen und könnte nichts mit diesen Werte anfangen, um die orignial Kommuniikation zu erfahren. Bei einer Fälschung würde er folgendes brechnen: Er erzeugt eine gefälschte Nachricht m' und berechnet AES-CTR{K'}(m') = c' und d' = MAC{Km}(m') und erzeugt dadurch die gefälschte Nachricht n' = (c',d')! Nur die beiden Kommunikationspartner wissen, dass K' nicht Ke ist und die grundlage der Kommunikation ist grundsätzlich, dass dieses Fälschen IMMER möglich ist und keiner sagen kann, ob eine Nachricht n Original oder Fälschung ist.

Stimmt, hatte ich übersehen.

Sirke hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Sirke hat folgendes geschrieben : BenBE hat folgendes geschrieben : Ziel ist auch Forward Secrecy, jap. Wird durch korrekten DH ja erreicht! Nicht zwingend DH, aber korrekte Nutzung von kurzlebigen Session-Keys. Na dann mal raus, wie du Forward Secrecy OHNE DH erreichen möchtest... Wir dürfen den Session Key dazu NICHT vom Langzeitschlüssel ableiten!

DH ist 1. nicht das einzige Kex-Protokoll und 2. kann man DH auch mit reinen Zufallszahlen machen. So macht es z.B. Vuze.

Ach ja: Ein OTP besitzt Forward Secrecy - nur ist das etwas unhandlich

Sirke hat folgendes geschrieben :

Dann ist das Sinnvollste bisher wohl wirklich das Einbetten in ein bisher bestehendes Protokoll, welches auf jeden Fall legal ist und zur Not SSL/TLS unterstützt, aber auch ohne dieses Feature zufällige Daten enthalten kann. Anschließend kann man an das Protokoll im einzelnen Denken, wie man die Auth und den Key-Ex umsetzt!

Sollte man nicht erstmal wissen, welchen Ablauf man bzgl. Nachrichten benötigt, bevor man anfängt, zu planen, wie diese auf den physischen Layer gelegt werden?

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 :

I2P mit OTR wäre glaube die bessere Wahl. Onion Routing erzeugt nachvollziehbare Wege. Side Channel Attacke wäre hier mit ner Traffic-Messung möglich (Abwehr dadurch, dass sich das Netz intern anonym über die Traffic-Sitation unterhält und gegensteuert).

Ich kenne mich nicht soo gut mit den vielen Möglichkeiten für anonyme Netze aus, aber der erste Blick auf I2P ist schon mal nicht schlecht! Die genau Funktionsweise ist mir jedoch zur zeit nicht bekannt, aber auch irrelevant da meine Annahmen zur Zeit darauf beruhen, dass die Daten die richtigen Sender und Empfänger anonym erreichen.

Jede Partei kann * viele asymmetrische Schlüsselpaare besitzen, welche für eine Partei A mit pkAi und skAi, wobei i eine Nummer des veröffentlichen Schlüsselpaares darstellt, bezeichnet werden. Mit ID(Ai) wird die dazugehörige ID, dh Pseudionym bzw Zufallszahl (Hash) bezeichnet. Zu beachten ist, dass i keine öffentlich bekannte Nummer sein sollte, sondern lediglich hier zur Unterscheidung angewendet werden soll! Die Verschlüsselung unter einem pkXi oder skXi einer Nachricht m wird mit E{pkXi}( m ) bezeichnet!

Dann läuft die Authentifizierung der beiden Parteien ( A und B ) wie folgt ab:

Die ID(Xi) können verschiedene Formen haben z.B. nur der Hash des Schlüsselpaares, welches zwischen A und B bereits ausgetauscht wurde oder ein Zertifikat, welches bereits ausgetauscht wurde oder ein Zertifikat, welches noch nicht ausgetauscht wurde, aber dann von einer dritten vertrauenswürdigen Partei signiert sein muss.

Hierbei wird Anonymität gehalten, weil JEDE Partei, welche mindestens einen pkAi, pkBj kennt, diese Nachrichten erzeugen kann! Gleichzeitig kann A und B sicher sein, wenn die MACs korrekt ankommen, dass die Nachrichten bei dem Besitzer der zugehörigen sk's angekommen ist. Um einen Key-Imper-Attack auszuschließen, MUSS eine Verbindung von den IDs zu den gewünschten Pseudonymen herzustellen sein! Hierzu stehen viele verschiedene Verfahren zur Verfügung


Diese Auth mit den in eingen Posts zuvor vorgestellten Counter Mode Verschlüsselungen in einem anonymen Netz (I2P) müsste ein anonymes OTR ermöglichen! Gerade weil ALLE Nachrichten gefälscht werden können! Denkfehler? Angriffe?


PS: Zur Auth Fälschung! In dem Netz sollte die Möglichkeit bestehen, dass jeder Relay-Knoten diese Nachrichten als Man-In-The-Middle erzeugen und an A und B senden kann ohne dass diese beiden Parteien dies wollen! Sprich: Die Nachrichten zwischen allen Relay-Knoten und den Empfängern DARF NICHT signiert sein! Denke mal hier liegt das größte Problem von I2P. ABER BEACHTE: Wie genau die Pakete in I2P aussehen ist mir nicht bekannt und konnte ich auch noch niewo gut finden!

Recht guter Vortrag, der in die richtige Richtung gehen d[rfte ...

events.ccc.de/congre.../events/3702.en.html

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.