Komprimieren und dann verschlüsseln oder umgekehrt?


88

Ich schreibe ein VPN-System, das seinen Datenverkehr über das Netz verschlüsselt (AES256).

Grundsätzlich möchte ich meine Gedanken an Ihnen vorbeiziehen lassen, um sicherzustellen, dass ich dies in der richtigen Reihenfolge tue.

Momentan werden Pakete nur vor dem Versenden verschlüsselt, aber ich möchte ihnen eine gewisse Komprimierungsstufe hinzufügen, um den Datentransfer ein wenig zu optimieren. Keine starke Komprimierung - Ich möchte nicht die ganze Zeit die CPU auslasten, aber ich möchte sicherstellen, dass die Komprimierung so effizient wie möglich ist.

Meiner Meinung nach sollte ich die Pakete vor dem Verschlüsseln komprimieren, da ein unverschlüsseltes Paket besser komprimiert wird als ein verschlüsseltes. Oder umgekehrt?

Ich werde wahrscheinlich Zlib für die Komprimierung verwenden.

Lesen Sie mehr im Super User Blog .


4
Schreiben als "Programmieren"? Wäre dann besser für Stack Overflow geeignet.
Suma

4
Wenn ich nach der Programmierung gefragt hätte, ja, aber ich bin es nicht. Dies ist eine allgemeine Frage zum Komprimieren, dann zum Verschlüsseln oder zum Verschlüsseln und dann zum Komprimieren. Die Programmierseite ist nur der Kontext, aus dem ich die Frage stelle.
Majenko


Wahrscheinlich eine Frage, die am besten für security.stackexchange.com bestimmt ist
Jeff Ferland

1
Sie kennen sich dort mit Komprimierung aus, oder?
Majenko

Antworten:


176

Wenn die Verschlüsselung richtig durchgeführt wird, sind die Ergebnisse im Grunde zufällige Daten. Die meisten Komprimierungsschemata funktionieren, indem Muster in Ihren Daten gefunden werden, die auf irgendeine Weise ausgeschlossen werden können, und dank der Verschlüsselung gibt es jetzt keine. Die Daten sind vollständig inkomprimierbar.

Komprimieren Sie, bevor Sie verschlüsseln.


41
Wichtiger: Komprimierung fügt Entropie hinzu. Das Hinzufügen von Entropie ist gut für Ihre Verschlüsselung (schwerer zu brechen mit bekannten Klartextangriffen).
Olli

8
Das Verschlüsseln von Ressourcen kostet weniger Ressourcen, wenn Sie eine kleinere Datei verschlüsseln. Also vor dem Verschlüsseln komprimieren.
GAThrawn

9
@Olli - nicht unbedingt, wenn das Komprimierungsschema bekannten Text hinzufügt. Stellen Sie sich im schlimmsten Fall vor, Sie würden einen bekannten 512-Byte-Header auf der Vorderseite der Daten platzieren und eine Verschlüsselung im Blockmodus verwenden.
Martin Beckett

26
Ich bin mir nicht sicher, warum @ Ollis Kommentar positiv bewertet wird, da er falsch ist. es ist nicht nur bedeutend weniger wichtig, für eine halbwegs anständige Verschlüsselung sollte es überhaupt nicht wichtig sein . Das heißt, die Stärke der Verschlüsselung sollte völlig unabhängig von der Entropie der Nachricht sein.
BlueRaja - Danny Pflughoeft

8
Wenn Sie überhaupt komprimieren, kann dies nur vor dem Verschlüsseln der Nachricht durchgeführt werden. Beachten Sie jedoch, dass hierdurch möglicherweise Informationen über die Komprimierbarkeit der ursprünglichen Nachricht verloren gehen Kanal. Stellen Sie sich eine Datei mit fester Größe vor, die entweder alle Nullen oder eine Nachricht enthält. Die All-0-Datei führt zu einer geringeren Nutzlast bei einem angemessenen Komprimierungsschema. Wahrscheinlich kein Problem in diesem speziellen Anwendungsfall.
Edward KMETT

22

Vor der Verschlüsselung komprimieren. Komprimierte Daten können bei kleinen Änderungen der Quelldaten erheblich variieren, was die Durchführung einer differenziellen Kryptoanalyse sehr schwierig macht.

Wie Mr.Alpha hervorhebt, ist das Ergebnis sehr schwer zu komprimieren, wenn Sie es zuerst verschlüsseln.


12
Nun, das ist korrekt, wurde aber 2 Stunden vor Ihrer
Veröffentlichung

3

Auch wenn es vom konkreten Anwendungsfall abhängt, würde ich Encrypt-then-Compress empfehlen. Andernfalls könnte ein Angreifer Informationen aus der Anzahl der verschlüsselten Blöcke verlieren.

Wir gehen davon aus, dass ein Benutzer eine Nachricht an den Server sendet und ein Angreifer die Möglichkeit hat, vor dem Senden Text an die Nachricht des Benutzers anzuhängen (z. B. über Javascript). Der Benutzer möchte einige sinnvolle Daten an den Server senden, und der Angreifer möchte diese Daten abrufen. So kann er versuchen, verschiedene Nachrichten an die Daten anzuhängen, die der Benutzer an den Server sendet. Anschließend komprimiert der Benutzer seine Nachricht und den vom Angreifer angehängten Text. Wir gehen von einer DEFLATE LZ77-Komprimierung aus, daher ersetzt die Funktion dieselben Informationen durch einen Zeiger auf das erste Erscheinungsbild. Wenn der Angreifer also den gesamten Klartext reproduzieren kann, reduziert die Komprimierungsfunktion die Größe des Klartextes auf die ursprüngliche Größe und einen Zeiger. Und nach der Verschlüsselung kann der Angreifer die Anzahl der Chiffrierblöcke zählen, um festzustellen, ob seine angehängten Daten mit den Daten übereinstimmen, die der Benutzer an den Server gesendet hat. Auch wenn dieser Fall ein wenig konstruiert klingt, handelt es sich bei TLS um ein ernstes Sicherheitsproblem. Diese Idee wird von einem Angriff namens CRIME verwendet, um Cookies in einer TLS-Verbindung zu lecken und Sitzungen zu stehlen.

Quelle: http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf


2

Wenn Sie eine Nachricht komprimieren, projizieren Sie sie in eine niedrigere Dimension, sodass weniger Bits vorhanden sind. Dies bedeutet, dass die komprimierte Nachricht (unter der Annahme einer verlustfreien Komprimierung) dieselben Informationen in weniger Bits enthält (diejenigen, die Sie entfernt haben, waren redundant). ) Sie haben also mehr Informationen pro Bit und folglich mehr Entropie pro Bit, aber die gleiche Gesamtentropie wie zuvor, als die Nachricht nicht komprimiert wurde. Zufälligkeit ist nun eine andere Sache, und hier können die Muster bei der Komprimierung einen Schraubenschlüssel werfen.


1

Die Komprimierung sollte vor der Verschlüsselung erfolgen. Ein Benutzer möchte keine Zeit damit verbringen, auf die Übertragung von Daten zu warten, sondern muss diese sofort ausführen, ohne Zeit zu verlieren.


1

Komprimierung vor der Verschlüsselung, wie bereits erwähnt. Die Komprimierung sucht nach einer Struktur, die komprimiert werden kann. Die Verschlüsselung verschlüsselt die Daten, um zu verhindern, dass Strukturen erkannt werden. Wenn Sie zuerst komprimieren, ist die Wahrscheinlichkeit, dass Sie eine kleinere Datei haben und somit weniger Nutzdaten übertragen müssen, sehr viel höher. Die Verschlüsselung wird ihre Aufgabe unabhängig davon erfüllen, ob sie komprimiert ist oder nicht. Wie bereits erwähnt, ist es wahrscheinlich schwieriger, eine differenzielle Kryptoanalyse für eine komprimierte Datei durchzuführen.


Dies scheint eine Wiederholung der akzeptierten und zweiten Antworten zu sein. Jede Antwort sollte zu einer inhaltlich neuen Lösung der Frage beitragen.
Fixer1234

0

Komprimierung reduziert die Informationsentropie. Maximale Komprimierung minimiert die Entropie. Für perfekt verschlüsselte Daten (Rauschen) ist die maximale und minimale Entropie gleich.


2
Warten Sie, haben Sie das nicht rückwärts? Ich dachte, die Entropie nimmt zu, wenn die Redundanz abnimmt. Daher sollte die Komprimierung die Entropie erhöhen.
Zan Lynx

Nein, weniger Entropie = mehr Muster. Zufälligkeit hat die größte Entropie.
AbiusX

1
Aber es ist Informationsentropie, also dreht sich alles um Bedeutung. Zufälligkeit hat keine Bedeutung, daher gilt sie nicht. Ein englischer Satz kann Buchstaben haben, die sich ändern, und dennoch dasselbe bedeuten, so dass er eine niedrige Entropie hat. Ein komprimierter englischer Satz ist möglicherweise nicht lesbar, wenn sich ein einzelnes Bit so ändert, dass es das meiste enthält. Zumindest denke ich.
Zan Lynx

Bei Entropie geht es nicht um Sinn und Fähigkeit zu lesen oder zu verstehen, sondern um Muster. Komprimierte Dateien sind voller Muster.
AbiusX

1
@AbiusX: Richtig. Muster. Und je weniger Muster, desto mehr Entropie. Dies bedeutet, dass die Komprimierung, die alle wiederholten Muster durch eine einzige Kopie ersetzt, die Entropie erhöht.
Zan Lynx
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.