Verstecken der Länge eines Plaintexts

Folgendes hypothetische Problem: Ein Agent betreut drei Models in seiner Agentur. Das Expose des einen Models(A) ist 5 MB gross, dass des zweiten(B) 10MB und das des dritten(C) 15MB. Auf eine Kundenanfrage hin schickt er zwei gezippte, mit GnuPG verschlüsselte Exposees. Konkurrentin Eve fängt die Mail ab und und will wissen, welche zwei Models vorgeschlagen wurden. Eve kann die resultierenden Längen der möglichen Zip-Archive nachbilden: 21MB(B+C), 17MB(A+C) und 12MB(A+B). Die GnuPG-Chiffre hat eine Länge von 16,7 MB(16630), Eve produziert selbst die drei mögliche Chiffren und erhält die Längen 16.6(exakt 16630), 23.5 und 29.8 MB (Ich hab das im kB Bereich nachgestellt, die Filelängen werden exakt reproduziert). Eve weiss somit, dass der Agent die Exposees von A und B geschickt hat. Ein anderes Tool, Academic Signature, gibt zwar an, "Payload Size Camouflage" zu bieten, für die drei Varianten(THREEFISH 1024bit CNT, ECC) kommen aber bei mehreren Verschlüsselung auch klare Differenzen heraus; 12,2 -12,4 für A+B, 17,2 -17,4 für A+C und 21,8 - 22,1 für B+C. Die Längenverschleierung ist also klar unzureichend. Auch hier kann Eve auf die korrekte Kombination schließen. Ich habe ein furchtbar umständliches Papier zum Themenkomplex gefunden: http://cihangir.forgottenlance.com/papers/lengthhiding-corrected.pdf in dem, soweit ich das verstehe, die Schlussfolgerung gezogen wird, eine sichere Längenverschleierung wäre nicht praktikabel. Was haltet Ihr davon? Müssen wir mit solchen Verwundbarkeiten leben? Nutzt eine unzureichende Verschleierung (wie bei Academic Signature) überhaupt etwas ? Wäre eine stärkere Längenverschmierung(wie viel genau) besser? Kennt Ihr andere Verschlüsselungstools und wie machen die das?
 
ist defacto eine frage des overheads der noch als akzeptabel deffiniert werden kann ...

du kannst rein von der informationstheoretischen seite nicht beides haben: minimale größe der daten und längen uniforme dateien

willst du das problem lösen, gibt es dafür x ansätze...

z.B. könntest du statt eines zip archivs einen container álá truecrypt versenden

oder du könntest vor dem verschlüsseln die exposes alle auf die größe des größten padden und sie eben NICHT packen
 
Plaintextlänge verschleiern

Ja, mir ist das auch im Prinzip sympathisch, durch Padding als User selbst dieses Infomationsleck zu beseitigen. Wenn ich die Stückelung/Stückgrößen des Plaintextes kenne, kann ich manuell leicht in passender Weise padden und das Leck verhindern. Man muss nur immer selbst dran denken. Mir leuchtet ein, dass ohne Kenntnis der Stückelung ein Algorithmus keine Chance hat, die passende Padgröße zu finden. Eine unzureichende Verschleierung durch eigentlich zu kleine Pads wäre dann aber immerhin schon mal eine Verbesserung gegen die exakte Längenwiedergabe. Das würde dann wenigstens bei vielen Stücken und nicht zu inhomogener Stückelung helfen.... Truecrypt kommt eigentlich nicht in Frage. Ich weiss, dass das häufig missbraucht wird. Aber das ist ja mit dem XTS-Mode im Prinzip eine random access Verschlüsselung für "Data at Rest". Wenn man das für Chiffren für Transport über einen unsicheren Kanal verwendet, handelt sich man eine ganze Reihe viel größerer Informatioslecks und mangelnden Integritätsschutz ein: Disk encryption theory - Wikipedia, the free encyclopedia Vielen Dank für Deine Antwort! Gibt's noch andere Sichtweisen?
 
Ich glaube TrueCrypt war einfach nur ein Beispiel, weil es diese Container fixer Größe bietet (was implizites Padding bedeutet). Du kannst natürlich ein iso- oder ext2- filesystem einer bestimmten Größe bevorzugen und das dann durch gpg jagen (wo du dir den Algorithmus aussuchen kannst).

Bezüglich XTS: ich kenne mich da nicht so aus, aber wegen Integritätsbedenken: reicht es nicht eine Checksum in die Mail zu schreiben und sie zu signieren?

In meinen Augen ist das schon Sorgfalt auf sehr hohem Niveau. Da Eve anscheinend weiß, wie groß die einzelnen Archive sind, ist schon etwas im Vorhinein schiefgelaufen.
Ich würde vermutlich auch keine (asymmetrisch) mit gpg verschlüsselte Mail/Anhänge verschicken.
 
Zum Padding: Das muss wohl sein und auch manuell getan werden. Dann scheint es mir aber am einfachsten, in das Zip File mit den Exposees noch irgedein Dummyphoto ausreichender Größe dazuzupacken. Zu XTS: bei jeder random access Verschlüsselung, wie man es für Disk Encryption braucht, muss man bezüglich der Integrität und der Informationsleckage Kompromisse machen. Der Preis ist relativ hoch: Wenn Du jeden einzelnen Block digital signieren( oder MACen) würdest, würdest Du einen gigantischen Overhead kreieren. Beim Auslesen müsstest Du dann für jeden Block Signatur oder MAC prüfen und das System unendlich verlangsamen. Deshalb geht das aus praktischen Gründen nicht. Weiterhin, wenn ein einzelner Block vom Nutzer des Containers geändert wird, wird nur dieser Block geändert und aus praktischen Gründen nicht der gesamte Container. Du kannst ja nicht wegen eines geänderten Bit jedesmal die ganze Festplatte neu verschlüsseln und beschreiben. Wer also den letzten Container abgefangen hat und den neuen Container abfängt, kann ziemlich viel Information gewinnen: Wieviel wurde geändert und wo. Das ist eine ziemlich großes Informationsleck. Man sollte also random access Verschlüsselung(wie in Truecrypt und anderen Containerlösungen) nur verwenden, wenn man sie wirklich braucht. Natürlich könnte man durch eine digitale Signatur oder einen MAC des Containers die Integrität sicherstellen, aber dann ist der Vorteil des random access weg. Da wäre es dann weniger umständlich gleich eine Fileverschlüsselung wie in PGP oder Academic Signature zu verwenden, als erst die weichere Version zu nehmen und hinterher sowieso wieder eine andere Kryptolösung drüberzulegen. Die weit verbreitete Praxis, Truecrypt-Container zu verschicken, hat große Sicherheitsprobleme. Profis, wie bei der NSA, könnten sicherlich eine Menge herausziehen. Man sollte eigentlich davor warnen... Zur Sorgfalt auf hohem Niveau: Um genau die geht es mir, ich will der perfekten Verschlüsselung nahe kommen. Dazu muss das letze mögliche Informationsleck geschlossen werden. Und das ist genau die Information über die Klartextlänge. In Lehrbüchern und Vorlesungen heisst es gelegentlich, das ginge nicht. Das möchte ich so nicht akzeptieren. Deshalb wäre eine Lösung, die selbst neue Lecks reisst auch nicht attraktiv. @Thunder11 -> wieso würdest Du keine asymmetrisch mit gpg verschlüsselte Mailanhänge verschicken?. Mir wäre es gerade wichtig, bei der Kommunikation (im Bsp zwischen Agentur, Models und Kunden) mit öffentlichen Schlüsseln hantieren zu können. Das ist doch in der Praxis viel einfacher, als mit jedem Kommunikationspartner im geheimen einen symmetrischen Schlüssel vereinbaren zu müssen.
 
Bedrohungsmodell

Eins habe ich noch vergessen: " Da Eve anscheinend weiß, wie groß die einzelnen Archive sind, ist schon etwas im Vorhinein schiefgelaufen." Na ja. Eve kann sich diese Inforamtion relativ leicht beschaffen. Sie gibt sich drei mal als jeweils anderer Kunde mit anderen Wünschen aus und bekommt so einen recht guten Überblick über die Files des Agenten. Das ist ein durchaus realistisches Angriffsszenario.
 
Wer hat davon geredet, jeden einzelnen Block zu signieren?

Wieso ist der Vorteil des random-access weg, wenn ich den Hash des TrueCrypt-Containers signiere?

PGP E-Mail ist verdammt auffällig. Es kommt einfach drauf an, gegen wen du dich schützen willst, aber wenn du eine PGP Mail verschickst, fällst du auf. Und wenn du davon ausgehst, dass jede E-Mail abgefangen wird, dann kannst du davon ausgehen, dass alle PGP Mails bei in Amerika auf einem "Stapel" landen.

Und es gibt zwei Szenarien, die im Nachhinein diese gesamte Kommunikation aufdecken könnten: P=NP und Quantencomputer.

Wenn du der perfekten Verschlüsselung nahe kommen wirst, fehlt dir bei PGP dann nicht Forward Secrecy?

Ich verstehe, dass es praktisch vermutlich am einfachsten ist, E-Mail einzusetzen, aber ich denke es wäre sicherer, verbindungslose Protokolle zu verwenden (UDP), wo der Datenverkehr einfach unter dem Rest verschwindet und nicht zugeordnet werden kann und für einen Dritten einfach nur Noise ist (weil verschlüsselt).
Kennst du: tox ?

Aja und bezüglich szenario: Ich kann mich in dieses kunden/modell/exposee nicht wirklich hineinversetzen, sorry. Ist für mich einfach zu irrelevant.
 
Zuletzt bearbeitet:
Tox und co.

"Wer hat davon geredet, jeden einzelnen Block zu signieren?" Du kannst natürlich irgendein Zwischending machen, z.B. immer 100 Blöcke auf einmal signieren, dann must du aber für jede Bitänderung im Hunderterblock eine neue Signatur anfertigen. Jede einzelne Signatur dauert dann auch 100 mal so lange(abzüglich des Overhead für die ECC oder RSA Berechnung), weil Du jedes mal den Hash über hundert Blöcke berechnen musst. Und wenn der Gegner den letzten Container und den aktuellen Container abgefangen hat, kann er genau sehen wo wieviel geändert wurde - in diesem Beispiel auf 100 Blöcke genau. Bei Disk Encryption - und Truecrypt gehört dazu - kommst Du nicht darum herum, Kompromisse bei der Integritätssicherung zu machen. Man muss damit rechnen, dass die Container extrem groß werden können und kann nicht bei jeder Änderung eines Bit den ganzen Container neu signieren. zu "PGP-Mail ist auffällig" Ok, in UDP Paketen wird wahrscheinlich noch nicht so intensiv herumgesucht. Das wäre dann eher so ein Steganographie Ansatz. Allerdings kannst Du auf der Ebene nicht so leicht deine Anonymität wahren. Mit Mail geht das auch für Laien ganz einfach: Unter TOR/TAILS einen anonymen Yandex Mailaccount anlegen und immer nur über Tor-Birdy oder TAILS zugreifen. Forward Secrecy braucht Interaktivität, das ist beim Chatten ganz ok(beisst sich aber übrigens mit UDP - da musstesst Du häufig die Verbindung mit dem permanenten Schlüssel neu initialisieren, der Vorteil von FS wäre weg und neue Verwundbarkeiten gingen auf). Mir gefällt die offline-Kommunikation per Mail mit minimaler Interaktion. Niemals mehr als eine Nachricht über einen TOR-Circuit :) und dann wieder offline gehen. Das geht nicht praktikabel mit FS. FS dient zum Begrenzen der Auswirkungen eines Breaches, ich möchte zunächst eine möglichst gute Abwehr gegen jedes Informatiosleck an der kritischen Stelle und nicht schon vorher einen zweiten oder dritten Burggraben ausheben. Kann man sicher auch anders sehen... Tox: kenne ich noch nicht, hab ich mir eben kurz angesehen. Die technische Dokumentation zur verwendeten Kryptographie war ein bisschen spärlich. Die Anonymität herzustellen scheint schwieriger, als über Mail und an einer Stelle wird's ein bisschen wachsweich und ich müsste den Tox-Leuten bezüglich des Schutzes meiner IP-Adresse vertrauen. Abgesehen davon sieht es für Chat ganz geeignet aus. "Beispiel irrelevant" -> Nenn sie nicht Model und Agent, sondern Alice und Bob. Gehts dann? Ich kann schon verstehen, dass man nicht jedem Gedanken eines anderen hinterherkreichen mag(geht mir auch manchmal so). Wenn man dann Glück hat, war's wirklich irrelevant. Natürlich haben wir verschiedene Vorstellungen davon, an welcher Stelle man wie genau sein muss. Entschuldige die mühselig zu lesende Formatierung, aber ohne JavaScript gehen wohl die schönen Icons nicht...
 
Tox

Ich habe gerade versucht, einen Tox client herunterzuladen. Folgende Probleme machen mir Kopfzerbrechen: 1.) Ich finde keinen sourcecode zum selbst kompilieren auf der offiziellen Download site 2.) Auf Github für gTox (hatte ich mir als client ausgesucht)finde ich keinen authentifizierten Code/ keine digitale Signatur 3.) Im read.me werde ich gewarnt, die Software noch nicht "for production" zu verwenden 4.) Es gibt einen Hinweis für Linux: "Check how to build", ich finde aber kein Dokument dazu auf Github und auch nicht auf der offiziellen Tox webpage. Das macht alles noch keinen sehr guten Eindruck und ich muss zum Ausprobieren und Testen wohl noch ein bisschen zuwarten. Speziell das Fehlen von Authentifizierung ist für solche Software eigentlich ein no go. Die programmieren doch sowas, da müsste doch eine PGP-Signatur des Entwicklers für den Download drin sein - hmmmm
 
Es wäre ja schön, wenn du zumindest manchmal auf die Enter-Taste hauen würdest, um unterschiedliche Gedankenstränge voneinander zu trennen. Smileys braucht es dazu nicht.

1. Tox-Source-Code: GitHub - irungentoo/toxcore: The future of online communications.

2. Tox/gTox nicht signiert: Macht das einen Unterschied? Du benutzt eine Software nicht, weil du genau weißt, wer sie entwickelt hat. Die Änderungen kannst du ja in git nachvollziehen.
Binärpakete gehören signiert. Über HTTPS auf github, sollte es keine MitM-Attacken geben.

3. Ja sorry, es ist noch in Entwicklung - nicht wirklich stable. Aber ich betrachte es als sehr guten Ansatz.

4. Du vertraust wirklich niemandem, gell? Ich verwende die Binärpakete für Debian. Die werden direkt von den tox-Leuten gebuildet und mit einem 4096 bit key signiert.
Ich wäre natürlich glücklicher, wenn Debian die Pakete selber bauen würde, aber ich schätze Mal, wenn überhaupt, gibt es tox bisher nur in unstable.
 
Zuletzt bearbeitet:
Tox

Ja, das TOX-Konzept ist sehr interessant. Nicht unbedingt wegen des chats, sowas gibts schon in einigermassen befriedigender Form. ********************************** Neu ist aber, dass die TOX-Leute sich auch um Media-Streams kümmern wollen, um das verhintertürte Skype zu ersetzen. Da gibt es derzeit ganz klar eine Versorgungslücke, die besonders bei eher IT-fernen, politisch aktiven Leuten und leider auch bei manchen organisierten Kriminellen gefühlt wird. Da gibt’s natürlich aber auch besonders harte Anforderungen an die Effizienz der Verschlüsselung. Mal sehen, ob das die TOX-Leute mit SALSA und der Bernstein-ECC-kurve gut hinkriegen. ************************************ Es scheint mir dabei konsequent, die Bernstein-Sachen zu verwenden, der trägt ja immer eine hohe Arbeitgeschwindigkeit als “Superziel” vor sich her. Das hat den angenehmen Nebeneffekt, dass von der NSA/NIST favorisierte Algorithmen keine Rolle spielen. Mag nötig sein, oder auch nicht, fühlt sich jedenfalls besser an. ************************************** Kehrseite ist, dass die TOX-Entwickler, zumindest wenn die Entwicklungen gut laufen und TOX sich verbreitet - was ich jetzt noch nicht sehen kann-, die staatlichen Dienste anziehen werden, wie Kuhscheiße die Fliegen. Da können die nicht vorsichtig genug sein und müssen mit Sabotage, Rufschädigung und Unterwanderungsversuchen rechnen! Wenn die schon anonym gegenüber den Usern sein wollen, sollten sie auf jedenfall peinlichst auf harte Anonymität auch gegenüber staatlichen Diensten achten, sonst wär die Anonymität nur alberne Show. ************************************* Zur Form: Die Returns werden mir beim Posten im Hackerboard immer weggeschnitten. Ich probier’s jetzt mal über einen Editor in wine...Mist, geht auch nicht.
 
Zurück
Oben