Zuerst komprimieren und dann verschlüsseln oder andersherum?

[BKempf]

Ich bin gerade dabei, spaßeshalber ein eigenes erweiterbares binäres Archivformat (nicht XML-basiert) zu definieren und will mir die Möglichkeit offenhalten, Verschlüsselungen zu benutzen; Komprimierung ist schon möglich. Dafür muß ich aber jetzt schon wissen, ob es sinnvoller ist, die zu verpackenden Daten erst zu komprimieren und das Ergebnis dann zu verschlüsseln oder umgekehrt, oder ob beide Reihenfolgen ihre Vor- und Nachteile haben. In den ersten beiden Fällen würde ich nur Flags für "ist komprimiert" und "ist verschlüsselt" vorsehen, wobei die Reihenfolge dann fest wäre; im letzten Fall käme noch ein Flag "Reihenfolge" hinzu. Zusätzlich sind ohnehin noch weitere Infos wie z.B. über die genutzten Algorithmen vorgesehen.

Lemma:
0. Sowohl Komprimierung als auch Verschlüsselung erzeugen aus mehr oder weniger redundanten Daten einen Output, der üblicherweise näher am "weißen Datenrauschen" liegt als das Original.

Meine Pluspunkte für die Strategie "Erst komprimieren, dann verschlüsseln":
1. (Mit Lemma 0) Die Originale sind vermutlich besser einzudampfen als schon verschlüsselte Dateien.
2. Eine verschlüsselte Datei, die erst dann komprimiert wird, erlaubt es einem etwaigen Angreifer, zuerst die Komprimierung "abzuschälen" und sich dann um die Verschlüsselung zu kümmern; ist dann noch ein Teil der Klartexte bekannt, könnte der Angriff dadurch u.U. vereinfacht werden. Liegt dagegen die Verschlüsselung außen, muß der Angreifer sich zuerst durch diese hindurcharbeiten (hat also keine schnellen Erfolgserlebnisse), und zudem dürfte ihm ein teilweise bekannter Klartext ein Stückchen weniger nützen, da ihm noch die Komprimierung im Weg ist.

* Habe ich bei einem der Punkte 0 oder 1 einen Denkfehler?
* Liege ich mit der Vermutung richtig, daß Punkt 2 Glaubenssache ist? Mir ist durchaus klar, daß mehrere verschiedene Verschlüsselungen (die innenliegende Komprimierung kann man hier im besten Fall als extrem schwache Verschlüsselung, eher als Verschleierung betrachten, da der Komprimierungsalgorithmus bekannt wäre) aufeinander angewandt keine Verbesserung der Sicherheit bringen (solange nichts gegenteiliges bewiesen ist). Trotzdem interessiert mich, ob die zwischen Klartext und Verschlüsselung liegende Komprimierung den Angriff erschwert, oder das Problem nur in Richtung eines anderen "virtuellen" Schlüssels verlagert (so wie bei zwei aufeinander ausgeführten Caesar-Verschiebungen mit unterschiedlichen Verschiebungen nicht zwei Schlüssel geknackt werden müssen, sondern nach wie vor nur einer, der aber so vermutlich nie eingegeben wurde) und eine "Sicherheit von minus hundert Prozent" ergäbe.

[St.Pauli]

Erst komprimieren, dann verschlüsseln. Dann hast du erstens den Vorteil, dass du dir Zeit sparst und zweitens den Vorteil, dass die Datei mit Sicherheit kleiner sein wird als umgekehrt. Denn wenn du erst verschlüsselst und dann komprimierst, solltest du bei einem guten Algorithmus nicht mehr viel komprimieren können.

[turboPASCAL]

Bei einer guten Datenverschlüsselung wird das Ergebniss immer grösser sein als das Original.
Wenn du vor der Komprimierung die Daten Verschlüsselst hast du bessere Möglichkeiten mit einem vernünftigen Algo. die Daten "Sicher zu verunstalten".
Den Hacker an sich wird es nicht interessieren ob die Daten erst Verschlüsselt und dann komprimiert oder aber Kkomprimiert und danach Verschlüsselt wurden.

Das was Wichtig sein sollte ist einfach wie sicher die Daten verschlüsselt werden.

Nun ist noch die Frage ob das Passwort bzw. der Schlüssel mit im Programm ist. Das macht's dem Angrifer ggf. einfacher.

[Phoenix]

Eine gute Verschlüsselung wie z.B. das One Time Pad erzeugt bei ausreichender Qualität der Zufallszahlen ein Ergebnis, das rein Zufällig ist. Und das lässt sich nicht mehr komprimieren.

Will heissen: Immer erst komprimieren, dann verschlüsseln, wenn es Dir um Platzersparnis geht.

Das vorherige Komprimieren der Daten bringt beim Knacken in sofern nichts, als dass der Hacker als "Klartext" allein schonmal den Komprimierungsheader hernehmen kann und zumindest mal weiss, wie die ersten Bytes aussehen müssten.

[turboPASCAL]

Zitat:

Und das lässt sich nicht mehr komprimieren.

Hä ?

Sorry, aber das glaube ich einfach nicht. Zumindest das der Algo. der Verschlüsselung dann gut sein soll.. dazu gesagt sei noch das ich "One Time Pad" nicht kenne oder davon gehört habe.

Zitat:

Das vorherige Komprimieren der Daten bringt beim Knacken in sofern nichts, als dass der Hacker als "Klartext" allein schonmal den Komprimierungsheader hernehmen

Ob ich nun vorher knacke und dann dekomprimiere oder andersherum ist doch Wurscht.

Den Algo der Komprimierung zu entschlüsseln ist dann wohl das einfachere.

[mkinzler]

Eine gute Verschlüsselung sorgt für eine gute Verteilung und läßt sich deshalb, wie Phoenix schon schrieb schlecht komprimieren. Deshalb ist das Verschlüsseln nach der Komprerssion imho besser. Das hat auch den Vorteil, daß man am Programm später weniger Ändern muß. Bei Archiven kann man die einzelnen Dateinamen verstecken, welche u.U. auch Rückschlüsse auf den Inhalt erlauben.

[Phoenix]

Zitat von turboPASCAL:

Zitat:

Und das lässt sich nicht mehr komprimieren.

Hä ?

Sorry, aber das glaube ich einfach nicht.

Ist aber so

Kurz mal zum Background:

Das One-Time-Pad benutzt ist eigentlich nix anderes als eine XOR-Verschlüsselung. Dabei ist der Schlüssel aber eine theoretisch unendlich lange Folge rein zufälliger Bits. Kannst auch Dein Weisses Rauschen nehmen Benutzt wird das z.B. zur Absicherung des heissen Drahtes zwischen Moskau und Washington, und auch unsere Botschaften benutzen das zur Kommunkation mit Berlin. Dabei wird eine extrem lange Zufallsfolge an Bits erzeugt (z.B. aus kosmischer Hintergrundstrahlung) und auf zwei Festplatten abgelegt. Die eine bleibt hier und die andere nimmt der Botschafter im Aktenköfferchen mit Handgelenkschellen mit. Und dann wird jedes Bit der Kommunkation mit einem der zufälligen Bits auf der Platte verschlüsselt. Solange keiner an eine der beiden Platten kommt kann er mit den Daten nix anfangen, denn die sehen für ihn aus wie genau eben jene kosmische Hintergrundstrahlung.


Zur Komprimierung:

Reinen Zufall kann man nicht verlustfrei komprimieren, da hier keine Redundanz vorliegt. Und Kompimieren geht ja nur, wenn man Redundanzen findet, die gross genug sind, um sie mit einem kleineren Datenstück zu repräsentieren. Da wir beim Zufall aber keine Redundanzen haben lässt sich nichts komprimieren.

Das bedeutet letzlich: Je besser der Verschlüsselungsalgorithmus (also je näher das Ergebnis einem reinen Zufallsdatenstrom kommt), desto weniger Redundanzen sind drin und desto schlechter lässt sich das Ergebnis komprimieren.

[turboPASCAL]

Was wird wohl negaH dazu sagen ?

[mkinzler]

Zitat von turboPASCAL:

Was wird wohl negaH dazu sagen ?

Sicherlich nichts Anderes als wir.

[BKempf]

Zitat von Phoenix:

Das vorherige Komprimieren der Daten bringt beim Knacken in sofern nichts, als dass der Hacker als "Klartext" allein schonmal den Komprimierungsheader hernehmen kann und zumindest mal weiss, wie die ersten Bytes aussehen müssten.

Mein Archiv besitzt einen "Rahmen" für die Metadaten, sowie mehrere Datenbereiche. Die Datenbereiche können jeweils separat komprimiert und verschlüsselt werden (u.U. mit unterschiedlichen Schlüsseln oder Algorithmen), ebenso der Rahmen. Die Rahmenverschlüsselung hat keine direkte Auswirkung auf die Daten, außer daß ein Angreifer evtl. Schwierigkeiten haben könnte, herauszufinden, wo ein Datenbereich beginnt und wo er endet (der Rahmen ist über die ganze Archivdatei verteilt).
Ein Dateiheader existiert nur insoweit, als die Dateiinfos (Größe, Zeitstempel, Attribute, verwendete Algorithmen für Kompression und Verschlüsselung) im Rahmen zusammengefaßt sind und mit dem Dateischlüssel nur der reine Dateiinhalt verschlüsselt wird. Zusätzlich könnte ich noch ein paar (Pseudo-)Zufallsdaten mitverschlüsseln, um Angriffe mit bekanntem Klartext zu erschweren (hatte Hagen neulich irgendwo vorgeschlagen).

Insgesamt decken sich eure Infos mit meiner Vermutung, dass ich erst komprimieren und danach verschlüsseln sollte.