Frage:
Verschlüsselung und Komprimierung von Daten
Ali Ahmad
2012-09-10 16:25:49 UTC
view on stackexchange narkive permalink

Wenn wir während der Übertragung sowohl Verschlüsselung als auch Komprimierung wünschen, ist dies die am meisten bevorzugte Reihenfolge.

  1. Verschlüsseln, dann komprimieren
  2. Komprimieren, dann verschlüsseln
  3. ol>
Integritätsschutz nicht vergessen. In den meisten Einstellungen ist dies genauso wichtig wie die Verschlüsselung. Dies kann mit MACs (z. B. [HMAC] (http://en.wikipedia.org/wiki/Hmac)) in einer symmetrischen Einstellung oder mit Signaturen in einer asymmetrischen Einstellung erfolgen.
Das sieht nach einer Frage aus den Prüfungen des Coursera-Kryptografiekurses aus.
Fünf antworten:
#1
+66
Polynomial
2012-09-10 16:31:57 UTC
view on stackexchange narkive permalink

Sie sollten vor dem Verschlüsseln komprimieren.

Durch die Verschlüsselung werden Ihre Daten in Daten mit hoher Entropie umgewandelt, die normalerweise nicht von einem zufälligen Stream zu unterscheiden sind. Die Komprimierung basiert auf Mustern, um eine Größenreduzierung zu erzielen. Da die Verschlüsselung solche Muster zerstört, kann der Komprimierungsalgorithmus Sie nicht (wenn überhaupt) erheblich verkleinern, wenn Sie ihn auf verschlüsselte Daten anwenden.

Die Komprimierung vor der Verschlüsselung erhöht auch geringfügig Ihren praktischen Widerstand gegen die differenzielle Kryptoanalyse (und bestimmte andere Angriffe), wenn der Angreifer nur den unkomprimierten Klartext steuern kann, da die resultierende Ausgabe möglicherweise schwer abzuleiten ist.

BEARBEITEN: Ich bearbeite diese Jahre später, weil Dieser Rat ist in einem interaktiven Fall eigentlich schlecht. In den meisten Fällen sollten Sie Daten nicht komprimieren, bevor Sie sie verschlüsseln. Eine als "Komprimierungsorakel" bekannte Seitenkanal-Angriffsmethode kann verwendet werden, um Klartextdaten abzuleiten, wenn der Angreifer interaktiv dazu führen kann, dass Zeichenfolgen in einen ansonsten unbekannten Klartext-Datenstrom eingefügt werden. Beispiele hierfür sind Angriffe auf SSL / TLS wie CRIME und BREACH.

Die Komprimierung kann jedoch in einigen [Kontexten] neue Angriffe ermöglichen (http://security.stackexchange.com/a/19914/655).
Wow, ich wusste noch nie von diesem Angriff. Tolles Schreiben auch!
Der Versuch, verschlüsselte Daten zu komprimieren, ist eine Möglichkeit, die Diffusionseigenschaft des Verschlüsselungsalgorithmus zu testen. Er ist auch ein Test für Schlüsselmaterial. Weder sollte in einer perfekten Welt überhaupt komprimieren.
@lynks Es ist jedoch kein endgültiger Test der Zufälligkeit. Wenn die verschlüsselte Datei nicht komprimiert wird, ist Ihre Verschlüsselung kein kompletter Scherz, kann aber im Extremfall sehr unsicher sein. Wenn die verschlüsselte Datei komprimiert wird, ist alle Hoffnung verloren und Sie können den Klartext auch den Bösen übergeben.
Hinzu kommt, dass echte Zufälligkeit von Zeit zu Zeit zufällige Muster enthalten sollte, sodass man in einer ausreichend großen Stichprobe ohnehin hier und da ein paar Bytes komprimieren kann.
@ewanm89 Potenziell. In der Realität benötigen Sie zum Ausführen angemessene Läufe, und die meisten Algorithmen haben einen gewissen Metadaten-Overhead pro "Block" komprimierten Textes. Daher ist es unwahrscheinlich, dass Sie die Gewinnschwelle erreichen.
@ewanm89: Die Anzahl der möglichen komprimierten Nachrichten der Länge * n * darf nicht größer sein als die Anzahl der möglichen Nachrichten der Länge * n *. Wenn wir also über die Menge aller möglichen Nachrichten mitteln, kann das durchschnittliche Komprimierungsverhältnis (komprimierte Größe geteilt durch unkomprimierte Größe) nicht weniger als 100% betragen. Komprimierungsalgorithmen erreichen reale Komprimierungsverhältnisse von weniger als 100%, indem sie auf gängige Muster auf * Kosten * ungewöhnlicher Muster abzielen. Daher hat eine wirklich zufällig generierte Nachricht normalerweise ein Komprimierungsverhältnis von mehr als 100%.
@ruakh nur, wenn Sie in den Metadaten kontern, wie Polynom sagt, ja, es ist unwahrscheinlich, dass sich das Muster so oft wiederholt, dass das Wörterbuch größer ist als die Komprimierung in den tatsächlichen Daten. Natürlich ist eine Blockverschlüsselung im EZB-Modus in der Regel stark komprimierbar, gibt dann aber keine zufällige Ausgabe und ist offen für Wörterbuchangriffe.
#2
+26
Thomas Pornin
2012-09-15 20:23:32 UTC
view on stackexchange narkive permalink

Wenn Sie nach der Verschlüsselung komprimieren und die Komprimierung etwas Gutes bewirkt (d. h. sie reduziert die Länge wirklich um einen nicht zu vernachlässigenden Betrag), können Sie die Verschlüsselung fallen lassen, sie ist schrecklich schwach. Verschlüsselter Text sollte nicht von Zufälligkeit zu unterscheiden sein. Selbst schlecht verschlüsselte Daten können normalerweise nicht komprimiert werden.

Komprimieren Sie daher vor der Verschlüsselung. Aus diesem Grund unterstützen Protokolle, die sich mit Verschlüsselung befassen, normalerweise die Komprimierung, z. OpenPGP (Abschnitt 5.6) und SSL / TLS. In einigen Szenarien kann durch die Komprimierung Informationen über vertrauliche Daten verloren gehen (da durch die Komprimierung die Länge abhängig von den Daten verringert wird und die verschlüsselte Länge mehr oder weniger der Klartextlänge entspricht). Dies ist die Idee hinter dem neuen CRIME-Angriff auf SSL / TLS.


Randausnahme: Wenn Sie eine Nachricht mit OpenPGP verschlüsseln und dann "ACSII-Rüstung" das Ergebnis , dh in Base64 codieren, dann vergrößert diese Codierung die Daten um 34%: 3 Bytes werden zu 4 Zeichen (plus der ungeraden Zeilenumbruch). Durch die Komprimierung mit DEFLATE wird diese Erweiterung wirksam abgebrochen (dank Huffman-Codes). Das ist ein Fall von Nützlichkeit der Komprimierung nach der Verschlüsselung - aber das ist wirklich mehr Komprimierung über Base64 als Komprimierung über Verschlüsselung.

#3
+8
Raphael Ahrens
2012-09-10 16:39:03 UTC
view on stackexchange narkive permalink

Ich würde empfehlen, die Daten zuerst zu komprimieren und dann zu verschlüsseln.

  1. Der Komprimierungsalgorithmus könnte von der Kenntnis der Datenstruktur profitieren und diese Struktur würde durch die Verschlüsselung verschleiert . Ein Beispiel wäre MP3, mit dem nur Audiodaten komprimiert werden können.

  2. Sie müssten weniger Daten verschlüsseln. Während Sie beim ersten Verschlüsseln und anschließenden Komprimieren keine Beschleunigung erzielen.

  3. ol>
#4
+3
hobs
2019-04-21 03:17:38 UTC
view on stackexchange narkive permalink

Weder noch: Komprimieren Sie während der Verschlüsselung mit einem Verschlüsselungstool, das beides sicher ausführen kann, z. B. GPG / OpenPGP.

Dies ist im Grunde die Antwort von Thomas Pornin, nur direkter, damit die Leser in Eile die Feinheiten dessen, was Thomas Pornin in seiner Antwort erklärt, nicht falsch verstehen. Die Frage drückt eine falsche Zweiteilung aus. Wenn das OP (und der Leser) daran denken, dass der erste und zweite Schritt die Ausführung von zwei verschiedenen Tools wie gzip und gpg :

    Wenn Sie zuerst verschlüsseln, wird die Komprimierung nicht viel bewirken, außer dass die von @ThomasPornin erwähnte Base64-Inflation von 34% der "ASCII-Rüstung" unterdrückt wird.

  1. Wenn Sie zuerst komprimieren, ist die Verschlüsselung weniger sicher und anfällig für Angriffe wie die von @ThomasPornin erwähnten.

  2. ol>
#5
+1
user466720
2019-11-06 08:19:12 UTC
view on stackexchange narkive permalink

Die Komprimierung nach der Verschlüsselung hat möglicherweise nicht die eigentliche Funktion zum Komprimieren von Daten, da dadurch die Größe nicht wesentlich verringert wird. Die Verschlüsselung nach dem Komprimieren ist zwar kleiner, führt jedoch nicht zum ordnungsgemäßen Funktionieren der Verschlüsselung, da Angriffe wie CRIME auftreten können.

Als Beispiel in Webanforderungen enthalten Header geheime Webcookies, daher werden die Header vor der Verschlüsselung komprimiert Geben Sie diese geheimen Informationen an die Außenseite weiter.

Daher ist es ratsam, eine selektive Komprimierung durchzuführen, bei der nur nicht geheime Daten auf der Seite komprimiert werden. Anschließend ist eine Verschlüsselung sinnvoll und verhindert das Extrahieren geheimer Informationen.

Kommt wirklich ein bisschen auf die Daten an.Durch die Komprimierung können sicherlich Informationen verloren gehen, es hängt jedoch von der Anwendung / dem Protokoll ab, ob diese Art von Informationen vertraulich ist.Beachten Sie, dass selbst unkomprimierte Daten Informationen über die Größe der Klartextnachricht verlieren.Bei der Komprimierung können jedoch auch Informationen über den Inhalt der Klartextnachricht verloren gehen, da einige Daten einfacher zu komprimieren sind als andere Daten.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...