nilsener1 - Sa 19.03.05 22:25
Titel: Verschlüsselte Datei komprimieren (winzip)

---

Hallo,

ich versuche eine mit Rijndael 256bit verschlüsselte datei per winzip zu komprimieren. leider klappt das nicht, die gezippte datei wird dabei sogar um ein paar bytes grösser. macht man es anders herum, erst zippen und dann verschlüsseln, dann gehts. wenn aber eine verschlüsselte datei nicht komprimiert werden kann, stelle ich mir die frage, ob eine gezippte datei vernünftig verschlüsselt wird ???

Hat da jemand erfahrung ?

gruss nilsener

AXMD - Sa 19.03.05 22:35

---

Das ist ein Riesenunterschied (erst ZIP, dann crypt oder erst crypt und dann ZIP). Beispiel: du hast eine Datei mit dem Inhalt AAAAAAAAAAAAAAAAAAAAAAAAAAAAA: Wird sie gezippt wirst du bemerken, dass sie eine sehr hohe Komprimierung erzielt (klar, Redundanz ;)). Diese Datei (ZIP) kannst du verschlüsseln und die Größe wird gleich bleiben.
Verschlüsselst du allerdings vor dem Zippen kommt in dem String, der vorher AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA war vielleicht kein einziger Buchstabe mehr doppelt vor und du hast eine entsprechend schlechtere Kompromierung. Und da ZIP noch den Dateinamen mitspeichern muss kann es durchaus sein, dass die Datei dann um ein paar Byte größer wird ;)

AXMD

nilsener1 - Sa 19.03.05 22:38

---

Danke,

das ist verständlich und klingt logisch.

Gruss nilsener

nilsener1 - Sa 19.03.05 23:10

---

ich möchte das thema doch nochmal aufgreifen. ich kann mir nicht vorstellen, das ein crypt immer ein ergebnis ohne (also mit null redundanz) liefert. ich habe es jetzt auch nochmal mit einer grösseren datei ca. 0.5 MB ausprobiert, mit dem selben ergebnis. ganz ganz einfach ausgedrückt würfelt das crypt die daten ja auch 'nur' durcheinander (es steckt natürlich mehr dahinter). die vorstellung von null redundanz fällt mir etwas schwer. vielleicht ist es bei anderen verschlüsselungsverfahren anders, diese frage können vielleicht aber nur herr rijn und herr dael (keine ahnung wie die richtig heissen) beantworten.

gruss nilsener

AXMD - Sa 19.03.05 23:17

---

Also dass eine 0,5MB-Datei null Redundanz hat kann ich mir kaum vorstellen; außer es ist ein Format, das selbst schon komprimiert ist (gif, jpeg, avi, mpeg, mp3,...)
Versuch mal eine größere Textdatei

AXMD

nilsener1 - Sa 19.03.05 23:32

---

hab es jetzt nochmal mit einer reinen txt datei der grösse 0,78 mb probiert, null prozent kompression der verschlüsselten datei. es ist unvorstellbar, aber es muss wohl am rijndael algorithmus liegen. ein anderer schlüssel bei crypt bringt auch keine verbesserung, wäre auch sehr merkwürdig gewesen.

gruss nilsener

wdbee - So 20.03.05 12:23

---

Wenn du eine Textdatei zippst, dann kommen dort nur vergleichsweise wenige Zeichen vor, die lesbaren. Wenn du das dann mit einem guten Verfahren verschlüsselst, dann kommen alle Zeichen drin vor. Deshalb wird das Komprimieren nach dem Verschlüsseln immer ein schlechteres Ergebnis liefern.

Durch das Verschlüsseln werden Strukturen verschleiert, die sonst für die Komprimierung ausgenutzt werden können. Auch in langen Texten werden immer wieder die gleiche Silben auftreten. Nach der Verschlüsselung ist das nicht mehr der Fall, denn sonst hätte man die Möglichkeit das statistisch zu analysieren und damit einen Angriff auf die Verschlüsselung starten.

Holgerwa - So 20.03.05 13:02

---

Alle Komprimieralgorithmen sind auf der Tatsache aufgebaut, daß sich in nutzbaren Daten (Texte, Bilder, usw.) Datenstrukturen wiederholen (Redundanz).
Es gibt ja auch Komprimierverfahren, die auf bestimmte Datentypen spezialisiert sind, also z.B. eine höhere Komprimierungsrate bei Bildern erzielen, da sie spezieller an die Datenstrukturen in Bilddateien angepaßt sind. Dann sind sie normalerweise nicht mehr so gut bei anderen Datentypen.
Die Verschlüsselung hat nun genau die Aufgabe, bekannte Datenstrukturen aus Nutzdaten zu entfernen, sodaß ein Rückschluß auf die Art und den Inhalt der Daten "unmöglich" wird. D.h. die Redundanz (also diejenige, die schlaue Leute für bestimmte Datentypen festgestellt haben) wird dadurch entfernt, und übrig bleibt eine für den Algorithmus "nicht-redundante" Datenmenge, an der er sich die Zähne ausbeißt. Es kann sogar noch größer als die Originaldaten werden, weil der Algorithmus ja noch einen Header hinzufügt.

Mit anderen Worten: Es ist sicherlich eine Redundanz in verschlüsselten Daten vorhanden, diese folgt aber nicht den Mustern, die von Komprimieralgorithmen erkannt werden.

Holger

nilsener1 - So 20.03.05 20:30

---

alles klar, jetzt verstehe ich es. vielen dank !!

gruss nilsener