Dokumentversion: 1.04 Zuletzt geändert: 30. Januar 2009
HINWEIS: Die Informationen auf dieser Seite sind für die Arbeit mit WinZip® nicht von Bedeutung, sondern lediglich für die Entwickler von Dienstprogrammen zur Verarbeitung von ZIP-Dateien gedacht.
Eine Übersicht über die seit der ursprünglichen Version in diesem Dokument vorgenommenen Änderungen finden Sie im Abschnitt Änderungsverlauf weiter unten auf dieser Seite.
In diesem Dokument wird das von WinZip für die Erzeugung AES-verschlüsselter ZIP-Dateien verwendete Dateiformat beschrieben. Die AE-1-Verschlüsselungsspezifikation wurde mit der im Mai 2003 herausgegebenen Version WinZip 9.0 Beta 1 eingeführt. Die AE-2-Verschlüsselungsspezifikation - eine Variante, die sich lediglich in der CRC-Verarbeitung von der ursprünglichen AE-1-Spezifikation unterscheidet - wurde mit der im Januar 2004 herausgegebenen Version WinZip 9.0 Beta 3 eingeführt. Beachten Sie, dass WinZip 11 selbst die meisten Dateien im AE-1-Format verschlüsselt und nur in Ausnahmefällen das AE-2-Format verwendet.
Diese Informationen werden bei Bedarf aktualisiert, beispielsweise um Änderungen an den Dateiformaten zu dokumentieren oder weitere Hinweise oder Tipps zur Implementierung bereitzustellen. Wenn Sie per E-Mail auf wesentliche Änderungen an diesem Dokument hingewiesen werden möchten, können Sie sich weiter unten in unsere Mailingliste "Developer Information" eintragen lassen.
WinZip Computing hat die Spezifikation des ZIP-Dateiformats um die Unterstützung der AES-Verschlüsselung erweitert, ohne das Dateiformat hierbei grundlegend zu verändern. Diese Erweiterung wird in dem vorliegenden Dokument ausführlich beschrieben. Außerdem erfahren Sie in diesem Dokument, wo Sie den aktuellen AES-Verschlüsselungscode kostenlos beziehen können. Hierbei handelt es sich um denselben Code, der auch von WinZip verwendet wird. Wir sind der Überzeugung, dass alle Entwickler mithilfe des frei verfügbaren Verschlüsselungscodes und dieser Spezifikation problemlos in der Lage sein werden, ihre ZIP-Dateidienstprogramme mit kompatiblen erweiterten Verschlüsselungsmechanismen auszustatten.
Dieses Dokument soll kein Tutorial zum Thema Verschlüsselung oder Archivdateistruktur darstellen. Zwar haben wir versucht, die notwendigen Detailinformationen zum aktuellen WinZip AES-Verschlüsselungsformat bereitzustellen, für die Umsetzung dieser Informationen in eigenen Programmen wird jedoch eine grundlegende Kenntnis der Verschlüsselungskonzepte, des ZIP-Dateiformats usw. benötigt.
Darüber hinaus empfehlen wir dem Entwickler einen Besuch der Seite Tipps zur AES-Kodierung für Entwickler.
WinZip Computing übernimmt keinerlei Garantie für die in diesem Dokument enthaltenen Informationen. Insbesondere bietet WinZip Computing keine Gewähr für die Fehlerfreiheit dieser Informationen oder ihre Eignung für einen bestimmten Zweck sowie dafür, dass das hier beschriebene Dateiformat auch in künftigen WinZip-Versionen unterstützt wird. Es wird ausdrücklich empfohlen, jeglichen Code und alle Verfahren mit der üblichen Sorgfalt zu testen und zu validieren.
Inhalt
Die von WinZip verwendeten AES Encryption- und Decryption-Funktionen wurden von Dr. Brian Gladman geschrieben. Der Quellcode dieser Funktionen kann als C/C++- und Pentium-Assemblercode von Jedermann von der AES-Projektseite auf Dr. Gladmans Website heruntergeladen und unter einer Open-Source BSD- oder GPL-Lizenz eingesetzt werden. Weitere Informationen zur Verwendung dieser Funktionen finden Sie auf der Seite Tipps zur AES-Kodierung für Entwickler. WinZip Computing dankt Dr. Gladman für die Bereitstellung seiner AES-Funktionen zu außerordentlich freizügigen Lizenzbedingungen.
Dr. Gladmans Verschlüsselungsfunktionen lassen sich für den Einsatz unter verschiedenen Betriebssystemen portieren und statisch in eigene Anwendungen einbinden und sind somit weder von einer bestimmten Betriebssystemversion abhängig noch auf bestimmte Bibliotheken angewiesen. Insbesondere die Microsoft Cryptography API ist für den Einsatz dieser Funktionen nicht erforderlich.
Allgemeine Informationen zum AES-Standard und dem Verschlüsselungsalgorithmus (dem so genanntenRijndael-Algorithmus) sind im Internet zu finden. Als Einstieg empfehlen wir die Seite http://www.nist.gov/public_affairs/releases/g00-176.htm.
AES-verschlüsselte Dateien werden gemäß den Richtlinien des ZIP-Standarddateiformats lediglich unter Verwendung eines neuen "Extradaten"-Felds, eines neuen Komprimierungsmethodencodes und einem von der Verschlüsselungsversion (AE-1 oder AE-2) abhängigen Wert im CRC-Feld gespeichert. Abgesehen hiervon bleibt das grundlegende ZIP-Dateiformat unverändert.
WinZip setzt die Felder "version needed to extract" und "version made by" im lokalen und zentralen Header auf dieselben Werte, die auch verwendet würden, wenn die Datei nicht verschlüsselt wäre.
Die von WinZip verwendete grundlegende ZIP-Dateiformatspezifikation steht auf dem FTP-Server der Info-ZIP-Gruppe unter der Adresse ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip zum Download bereit.
Wie bei allen verschlüsselten Dateien muss Bit 0 des Felds "general purpose bit flags" im lokalen Header und im Zentralverzeichniseintrag einer jeden AES-verschlüsselten Datei auf 1 gesetzt werden.
Außerdem wird Vorhandensein einer AES-verschlüsselten Datei in einem Archiv durch einen neuen Komprimierungsmethodencode (dezimal 99) im lokalen Header und Zentralverzeichniseintrag der Datei in Verbindung mit dem weiter unten beschriebenen AES-Extradatenfeld angezeigt. Die Codes version made by und version needed to extract bleiben unverändert.
Der Code für die verwendete Komprimierungsmethode selbst wird im AES-Extradatenfeld gespeichert (siehe unten).
Bei nach der AE-2-Methode verschlüsselten Dateien wird der standardmäßige ZIP-CRC-Wert nicht verwendet; in diesem Feld muss eine 0 gespeichert werden. Stattdessen wird eine Beschädigung verschlüsselter Daten in einer ZIP-Datei anhand des Wertes im Feld Authentifizierungscode erkannt.
Dateien, die nach der AE-1-Methode verschlüsselt wurden, enthalten den standardmäßigen ZIP-CRC-Wert. Neben der Tatsache, dass die im AES-Extradatenfeld gespeicherte Vendor-Version bei der AE-1-Methode 0x0001 und bei der AE-2-Methode 0x0002 lautet, ist dies der einzige Unterschied zwischen den Formaten AE-1 und AE-2.
HINWEIS: ZIP-Dienstprogramme, die das AE-2-Format unterstützen, müssen in der Lage sein, Dateien im AE-1-Format zu lesen, und beim Entschlüsseln/Extrahieren von Dateien im AE-1-Format prüfen, ob ihr tatsächlicher CRC-Wert mit dem im CRC-Feld gespeicherten Wert übereinstimmt.
Hinweis: Allgemeine Informationen zum Format und der Verwendung des Extradatenfelds finden Sie in der oben genannten Beschreibung des ZIP-Dateiformats.
| Offset | Größe (Byte) | Inhalt |
| 0 | 2 | Header-ID des Extrafelds (0x9901) |
| 2 | 2 | Datengröße (derzeit 7, künftig möglicherweise höher) |
| 4 | 2 | Ganzzahlige Versionsnummer, wird vom Vendor vergeben |
| 6 | 2 | Zweistellige Vendor-ID |
| 8 | 1 | Ganzzahliger Moduswert zur Angabe der AES-Verschlüsselungstiefe |
| 9 | 2 | Die tatsächlich verwendete Komprimierungsmethode |
ZIP-Dienstprogramme, die AE-2 unterstützen, müssen auch in der Lage sein, Dateien zu verarbeiten, die im AE-1-Format verschlüsselt wurden. Die Verarbeitung des CRC-Werts stellt den einzigen Unterschied zwischen den Formaten AE-1 und AE-2 dar.
| Wert | Verschlüsselungstiefe |
| 0x01 | 128-Bit-Schlüssel |
| 0x02 | 192-Bit-Schlüssel |
| 0x03 | 256-Bit-Schlüssel |
Die Verschlüsselungsspezifikation unterstützt nur 128-Bit-, 192-Bit- und 256-Bit-Schlüssel. Andere Schlüssellängen sind nicht zulässig.
(Hinweis: Die aktuelle WinZip-Version bietet keine Unterstützung für die Verschlüsselung von Dateien mit einem 192-Bit-Schlüssel. Da in dieser Spezifikation jedoch auch der Einsatz eines 192-Bit-Schlüssels vorgesehen ist, kann WinZip Dateien, die mithilfe eines solchen Schlüssels erzeugt wurden, entschlüsseln.)
III. Speicherformat verschlüsselter Dateien
Die für die Verschlüsselung benötigten Overhead-Daten werden in der verschlüsselten Datei selbst (d. h. nicht im Header) gespeichert. Das Format der gespeicherten Datei lautet wie folgt; weitere Informationen zu diesen Feldern finden Sie im Anschluss an die Tabelle. Alle Felder sind byte-aligned.
| Größe (Byte) |
Inhalt |
| variabel | Saltwert |
| 2 | Kennwortprüfwert |
| variabel | Verschlüsselte Dateidaten |
| 10 | Authentifizierungscode |
Beachten Sie, dass der Wert in den "compressed size"-Feldern des lokalen Dateiheaders und des Zentralverzeichniseintrags der Gesamtgröße der oben aufgeführten Werte (Saltwert, Kennwortprüfwert, verschlüsselte Daten und Authentifizierungscode) entspricht.
Der "SALT" oder "Saltwert" ist eine zufällige oder pseudozufällige Bytesequenz, die mit dem Verschlüsselungskennwort kombiniert wird, um die Verschlüsselungs- und Authentifizierungsschlüssel zu erzeugen. Er wird von der verschlüsselnden Anwendung generiert und in unverschlüsselter Form in den Dateidaten gespeichert. Die Kombination aus Saltwert und Kennwort bietet eine Reihe von Sicherheitsvorteilen und erschwert Wörterbuchattacken auf der Grundlage vorausberechneter Schlüssel erheblich.
Beim Verschlüsseln mehrerer Dateien mit einem gemeinsamen Kennwort muss laut den Kryptographierichtlinien für jede Datei ein anderer Saltwert verwendet werden. Wenn zwei Dateien mit demselben Kennwort und Saltwert verschlüsselt werden, können sie Informationen übereinander preisgeben. So ist es beispielsweise möglich festzustellen, ob zwei mit demselben Kennwort und Saltwert verschlüsselte Dateien identisch sind, und ein Angreifer, dem der Inhalt einer von zwei mit demselben Kennwort und Saltwert verschlüsselten Dateien aus irgendeinem Grund bekannt ist, kann den Inhalt der anderen Datei teilweise oder vollständig bestimmen. Aus diesem Grund wird dringend empfohlen, für jede Datei einen eigenen Saltwert zu verwenden.
Die Größe des Saltwerts hängt jeweils von der Länge des zugrunde liegenden Schlüssels ab:
| Schlüsselgröße | Salt-Größe |
| 128 Bit | 8 Byte |
| 192 Bit | 12 Byte |
| 256 Bit | 16 Byte |
Dieser Zwei-Byte-Wert wird während der Ableitung der Encryption- und Decryption-Schlüssel aus dem Kennwort generiert. Beim Verschlüsseln wird anhand des Verschlüsselungskennwort ein Prüfwert erzeugt und in der verschlüsselten Datei gespeichert. Vor dem Entschlüsseln kann ein Prüfwert aus dem eingegebenen Kennwort abgeleitet und mit dem in der Datei gespeicherten Wert verglichen werden. Anhand dieses Prüfwerts lassen sich die meisten (jedoch nicht alle) falschen Kennwörter sehr schnell erkennen. Die Wahrscheinlichkeit, dass sich bei der Auswertung eines falschen Kennworts der richtige Prüfwert ergibt, liegt bei 1 zu 65.536. Daher kann der Prüfwert nicht als absolut sicheres Merkmal zu Erkennung des korrekten Kennworts verwendet werden.
Informationen dazu, wie Sie den Kennwortprüfwert aus der Verschlüsselungsbibliothek von Dr. Gladman abrufen, finden Sie auf der Seite Tipps zur AES-Kodierung für Entwickler.
Dieser Wert wird in unverschlüsselter Form gespeichert.
Verschlüsselt werden nur die Inhalte der jeweiligen Dateien. Dies geschieht nach dem Komprimieren und betrifft keine der während des Komprimierungsvorgangs hinzugefügten Daten. Die Dateidaten werden byteweise mithilfe des AES-Verschlüsselungsalgorithmus im "CTR"-Modus verschlüsselt, sodass die verschlüsselten Daten dieselbe Länge aufweisen wie die komprimierten Daten vor der Verschlüsselung.
Bei der Implementierung ist zu beachten, dass die Daten trotz dieser byteweisen Verschlüsselung blockweise an die Encryption- und Decryption-Funktionen übergeben werden. Hierbei muss für die Verschlüsselung und die Entschlüsselung stets dieselbe Blockgröße verwendet werden. Die Blockgröße muss laut der Verschlüsselungsspezifikation 16 Byte betragen, wobei lediglich der letzte Block naturgemäß kleiner sein kann.
Die Authentifizierung stellt eine zusätzliche Sicherheitsmaßnahme dar, durch die geprüft wird, ob der Inhalt einer verschlüsselten Datei nach der Verschlüsselung versehentlich geändert oder absichtlich manipuliert wurde. Hierbei handelt es sich im Grunde um eine Super-CRC-Prüfung der Dateidaten nach der Komprimierung und Verschlüsselung. (Außerdem spielt die Authentifizierung bei der Verschlüsselung im CTR-Modus eine wichtige Rolle, da dieser Modus ohne Authentifizierung keinen ausreichenden Schutz vor verschiedenen trivialen Angriffen bietet.)
Der Authentifizierungscode wird von der Ausgabe des Verschlüsselungsvorgangs abgeleitet. Die Authentifizierung wird durch Dr. Gladmans AES-Code bereitgestellt. Informationen zur Ableitung des Authentifizierungscodes finden Sie auf der Seite Tipps zur AES-Kodierung für Entwickler.
Der Authentifizierungscode wird in unverschlüsselter Form gespeichert. Er ist byte-aligned und folgt unmittelbar auf das letzte verschlüsselte Datenbyte.
Weitere Informationen zur Authentifizierung finden Sie unter Authentifizierungscode - FAQ.
Mit WinZip 11 wurde eine Änderung in der Verwendung des AE-1- und des AE-2-Dateiformats vorgenommen. Die Dateiformate selbst wurden nicht geändert, und die von WinZip 11 erstellten AES-verschlüsselten Dateien sind vollständig kompatibel mit der im Januar 2004 veröffentlichten Version 1.02 der WinZip AES-Verschlüsselungsspezifikation.
In WinZip 9.0 und WinZip 10.0 wurden alle AES-verschlüsselten Dateien im AE-2-Dateiformat gespeichert, bei dem der CRC-Wert der verschlüsselten Datei nicht gespeichert wird. WinZip 11 hingegen verwendet das AE-1-Dateiformat, das bei den meisten Dateien den CRC-Wert beinhaltet. Dies bedeutet eine weitere Integritätsprüfung, bei der Hardware- oder Software-Fehler aufgedeckt werden, die während der eigentlichen Komprimierung/Verschlüsselung oder Entschlüsselung/Dekomprimierung auftreten können. Weitere Informationen zu diesem Thema finden Sie in der folgenden Beschreibung des CRC-Werts.
Da sich bei sehr kleinen Dateien anhand des CRC-Werts unabhängig von der verwendeten Verschlüsselungsmethode der genaue Inhalt einer Datei ermitteln lässt, verwendet WinZip 11 für Dateien mit einer unkomprimierten Größe von weniger als 20 Byte nach wie vor das AE-2-Dateiformat ohne gespeicherten CRC-Wert. Außerdem verwendet WinZip 11 das AE-2-Dateiformat für Dateien, die im BZIP2-Format komprimiert wurden, da das BZIP2-Format eigene Integritätsprüfungen beinhaltet, die den vom CRC-Wert des ZIP-Formats bereitgestellten Prüfungen entsprechen.
Andere Hersteller, die die von WinZip verwendete AES-Verschlüsselungsspezifikation unterstützen, sollten in ihren eigenen Implementierungen der Spezifikation ähnliche Änderungen vornehmen, um die Möglichkeit der zusätzlichen Integritätsprüfung zu nutzen.
Beachten Sie, dass bereits in Version 1.0.2. der WinZip AE-2-Spezifikation vom Januar 2004 festgelegt war, dass Dienstprogramme, die das AE-2-Format implementieren, auch in der Lage sein müssen, Dateien im AE-1-Format zu verarbeiten und beim Entschlüsseln/Extrahieren dieser Dateien den CRC-Wert zu überprüfen.
Im Hinblick auf eine möglichst geringe Größe der ZIP-Datei wird empfohlen, datenfreie Struktureinträge wie Ordner-/Verzeichniseinträge nicht zu verschlüsseln. Hierbei handelt es sich jedoch lediglich um eine Empfehlung. Auf die Gültigkeit der Archivdaten hat die Verschlüsselung dieser Einträge keine Auswirkung.
Auf der anderen Seite wird empfohlen, Dateien mit einer Länge von Null sehr wohl zu verschlüsseln, da manche ZIP-Dateidienstprogramme beim Entschlüsseln eines Archivs, das sowohl verschlüsselte als auch unverschlüsselte Dateien enthält, Warnmeldungen zurückgeben, die den Gesamteindruck beeinträchtigen können.
Beim Verschlüsseln von Dateien mit Nulllänge bleibt der verschlüsselte Datenbereich im Archiv leer (siehe oben). Die übrigen Overhead-Daten müssen jedoch sowohl im Dateispeicherbereich als auch im lokalen und zentralen Header vorhanden sein.
Laut Spezifikation ist es nicht notwendig, alle in einem Archiv enthaltenen Dateien zu verschlüsseln oder für alle verschlüsselten Dateien dieselbe Verschlüsselungsmethode oder dasselbe Kennwort zu verwenden.
Eine ZIP-Datei kann also sowohl unverschlüsselte Dateien als solche auch Dateien enthalten, die mit verschiedenen der vier derzeit definierten Encryption-Methoden (Zip 2.0, AES-128, AES-192 und AES-256) verschlüsselt wurden. Hierbei können die geschützten Dateien nach Belieben mit demselben Kennwort oder mit unterschiedlichen Kennwörtern verschlüsselt werden.
Die Ableitung des Schlüssels in AE-1 und AE-2 sowie in Dr. Gladmans Bibliothek geschieht mithilfe des in den RFC2-Richtlinien beschriebenen PBKDF2-Algorithmus mit einem Iterationswert von 1000. Hierbei werden eine angemessene Anzahl von Bits aus dem resultierenden Hashwert verwendet, um drei Ausgabewerte zu erzeugen: einen Encryption-Schlüssel, einen Authentifizierungsschlüssel und einen Kennwortprüfwert. Die ersten n Bits werden als Encryption-Schlüssel, die nächsten m Bits als Authentifizierungsschlüssel und die letzten 16 Bit (zwei Byte) als Kennwortprüfwert verwendet.
Bei dem in RFC 2898 definierten Verfahren muss eine Pseudozufallsfunktion aufgerufen werden; AE-2 verwendet zu diesem Zweck die HMAC-SHA1-Funktion, einen anerkannten Algorithmus, der bereits seit mehreren Jahren vielerorts erfolgreich eingesetzt wird.
Bitte beachten Sie, dass die HMAC-SHA1-Funktion ein 160-Bit-Ergebnis hervorbringt, sodass die Größe des Suchbereichs für den Schlüssel bei Verwendung der 192-Bit- oder 256-Bit-AES-Verschlüsselung unabhängig von dem angegebenen Kennwort mit großer Wahrscheinlichkeit nicht den theoretischen Maximalwert von 192 bzw. 256 Bit erreicht, sondern eher bei dem durch die Funktion garantierten Wert von 160 Bit liegen wird. Erläuterungen hierzu finden Sie in Abschnitt B.1.1 der RFC2898-Spezifikation.
Da bei der neuen Komprimierungsmethode keine neuen version made by- und version needed to extract-Werte verwendet werden, um die AES-Verschlüsselung einer Datei anzuzeigen, ist die Wahrscheinlichkeit höher, dass sich Archive, die nach dieser Methode erzeugt wurden, auch mit älteren Versionen vorhandener ZIP-Dateidienstprogramme verarbeiten lassen. In der Regel wird ein ZIP-Dateidienstprogramm nicht versuchen, mit einer unbekannten Methode komprimierte Dateien zu extrahieren, sondern stattdessen eine entsprechende Meldung zurückgeben.
Aus den oben erläuterten Gründen sollten beim Verschlüsseln mehrerer Dateien mit demselben Kennwort unterschiedliche Saltwerte verwendet werden. Allerdings ist es nicht leicht, dies sicherzustellen.
In der Praxis ist die in der AE-1- und der AE-2-Spezifikation für den Saltwert vorgesehene Anzahl von Bytes hoch genug, sodass die Verwendung eines Pseudozufallswerts ausreicht, um das Auftreten doppelter Saltwerte mit hinreichender Sicherheit auszuschließen.
Hierbei ist jedoch eine Ausnahme zu beachten: Wenn Sie die WinZip 128-Bit-Verschlüsselung mit 8-Byte-SALT-Werten verwenden, besteht die Wahrscheinlichkeit, dass bei etwa 4 Milliarden mit demselben Kennwort verschlüsselten Dateien zwei von ihnen denselben Saltwert aufweisen, sodass empfohlen wird, weit unterhalb dieser Anzahl von Dateien zu bleiben. Daher sollten Sie, wenn Sie eine große Anzahl von Dateien (d. h. in der Größenordnung von mehreren Millionen Dateien, also beispielsweise 2000 ZIP-Dateien mit jeweils 1000 verschlüsselten Dateien) anhand des WinZip AES-Verschlüsselungsformats mit einem gemeinsamen Kennwort verschlüsseln, anstelle der 128-Bit AES-Schlüssel mit ihren 8-Byte-SALT-Werten die 192-Bit oder 256-Bit AES-Schlüssel mit ihren 12- bzw. 16-Byte-SALT-Werten verwenden.
Die Saltwerte müssen nicht wirklich zufällig, jedoch in einer Weise erzeugt werden, die gewährleistet, dass die Wahrscheinlichkeit doppelter Saltwerte nicht wesentlich höher ist, als dies bei Verwendung echter Zufallswerte zu erwarten wäre.
Ein mögliches Verfahren zur Generierung von Saltwerten wird auf der Seite Tipps zur AES-Kodierung für Entwickler vorgestellt.
Der Zweck des Authentifizierungscodes besteht darin sicherzustellen, dass, nachdem die Daten einer Datei komprimiert und verschlüsselt wurden, versehentliche Beschädigungen der verschlüsselten Daten und Versuche, die verschlüsselte Daten ohne Kenntnis des Kennworts zu ändern, erkannt werden können.
In der Kryptographieszene ist man sich darüber einig, dass die Zuweisung eines Message Authentication Code (MAC) für verschlüsselte Daten im Hinblick auf die Sicherheit einen hohen Stellenwert einnimmt, da sie viele Angriffe deutlich erschwert. Dies gilt insbesondere für die Verschlüsselung im AES CTR-Modus, da in diesem Fall ohne MAC eine Reihe trivialer Angriffe erfolgreich sein können. Der bei der WinZip AES-Verschlüsselung verwendete MAC basiert auf dem HMAC-SHA1-80-Algorithmus, der allgemein als ausgereifter und wirksamer Authentifizierungsalgorithmus anerkannt ist.
Der MAC wird nach dem Komprimieren und Verschlüsseln der Dateninhalte einer Datei errechnet. Diese als "Encrypt-then-MAC" bezeichnete Reihenfolge der Verarbeitung wird von vielen Kryptographen gegenüber der alternativen "MAC-then-Encrypt"-Reihenfolge bevorzugt, da bei ihr einige bekannte Angriffe, denen das MAC-then-Encrypt-Verfahren ausgesetzt ist, ins Leere laufen.
Beim Zip-Format dient der CRC-Wert hauptsächlich dazu, eine versehentliche Beschädigung der in der ZIP-Datei gespeicherten Daten zu erkennen. Bei Dateien, die entsprechend der Zip-2.0-Spezifikation verschlüsselt wurden, dient er bis zu einem gewissen Grad auch als Methode zur Erkennung absichtlicher Versuche, die verschlüsselten Daten zu ändern, sofern diese nicht in Form starker kryptographischer Angriffe stattfinden. Bei der WinZip AES-Verschlüsselungsspezifikation wird der CRC-Wert für diesen Zweck nicht benötigt, da hier der HMAC-SHA1-basierte Authentifizierungscode diese Funktion übernimmt.
Ein Nachteil des CRC-Wertes besteht darin, dass sich mit seiner Hilfe unabhängig von dem verwendeten Verschlüsselungsalgorithmus der unverschlüsselte Inhalt sehr kleinen Dateien (bis maximal vier Byte) feststellen lässt. Grundsätzlich wird empfohlen, möglichst wenig Informationen zu der verschlüsselten Datei im unverschlüsselten ZIP-Header zu speichern.
Der CRC-Wert dient einem Zweck, den der Authentifizierungscode nicht erfüllt. Der CRC-Wert wird anhand des ursprünglichen, unkomprimierten und unverschlüsselten Inhalts der Datei berechnet und nach dem Entschlüsseln und Entkomprimieren der Datei überprüft. Im Gegensatz dazu wird der bei der WinZip AES-Verschlüsselung verwendete Authentifizierungscode nach dem Komprimieren/Verschlüsseln berechnet und vor dem Entschlüsseln/Entkomprimieren überprüft. In dem außerordentlich seltenen Fall, dass Daten aufgrund eines Hardware- oder Software-Fehlers während der Komprimierung und Verschlüsselung oder während der Entschlüsselung und Enkomprimierung beschädigt werden, wird dieser Fehler anhand des CRC-Werts erkannt, nicht jedoch anhand des Authentifizierungscodes.
In WinZip 9.0 und WinZip 10.0 wurde für alle Dateien das AE-2-Verfahren verwendet und der CRC-Wert nicht gespeichert. Im Gegensatz dazu wird seit WinZip 11 für die meisten Dateien das AE-1-Verfahren verwendet und der CRC-Wert als zusätzliche Integritätsprüfung zur Erkennung von Hardware- oder Software-Fehler verwendet, die während der Komprimierung/Verschlüsselung oder Entschlüsselung/Entkomprimierung aufgetreten sind. Für sehr kleine Dateien von weniger als 20 Byte verwendet WinZip 11 allerdings weiterhin das AE-2-Verfahren ohne CRC-Wert. Dies gilt auch für komprimierte Dateien im BZIP2-Format, da dieses Format interne Integritätsprüfungen beinhaltet, die der CRC-Prüfung entsprechen.
Beachten Sie, dass die von WinZip 11 erstellten AES-verschlüsselten Dateien vollständig kompatibel mit der im Januar 2004 veröffentlichten Version 1.0.2 der WinZip AES-Verschlüsselungsspezifikation sind, in der sowohl die AE-1- als auch die AE-2-Variante des Dateiformats bereits definiert war.
Änderungen gegenüber Dokumentversion 1.04 von Januar 2009: Die Beschreibung des zum Generieren des Authentifizierungscodes verwendeten Algorithmus wurde überarbeitet.
Änderungen gegenüber Dokumentversion 1.03 vom November 2006: Das Dokument wurde überarbeitet und an manchen Stellen geändert, um bestimmte Sachverhalte noch besser zu verdeutlichen. Außerdem wurden die folgenden wesentlichen technischen Änderungen vorgenommen:
Die WinZip AES-Verschlüsselungsspezifikation definiert zwei Formate, AE-1 und AE-2, die sich darin unterscheiden, ob der CRC-Wert der verschlüsselten Datei im ZIP-Header gespeichert wird oder nicht. Die Dateiformate selbst bleiben unverändert, nicht jedoch die Art und Weise, in der sie von WinZip verwendet werden. Seit WinZip 11 wird für viele verschlüsselte Dateien das AE-1-Format verwendet, das den CRC-Wert der verschlüsselten Datei beinhaltet, um eine zusätzliche Integritätsprüfung zur Erkennung von Hardware- oder Software-Fehlern bereitzustellen, die während der Komprimierung/Verschlüsselung oder Entschlüsselung/Entkomprimierung aufgetreten sind. Beachten Sie, dass die von WinZip 11 erstellten AES-verschlüsselten Dateien mit der früheren Version 1.0.2 der WinZip-Verschlüsselungsspezifikation vom Januar 2004 vollständig kompatibel sind.
Änderungen gegenüber Dokumentversion 1.02 von Januar 2004: Die Einleitung zu Beginn des Dokuments wurde umgeschrieben und der übrige Text an verschiedenen Stellen geringfügig überarbeitet und verdeutlicht. Außerdem wurden zwei wesentliche technische Änderungen vorgenommen:
In einer Standard-ZIP-Datei werden die CRC-Werte der unverschlüsselten Daten der einzelnen Dateien gespeichert. Diese Werte dienen dazu, Beschädigungen oder andere Veränderungen an ZIP-Dateien zu erkennen. Ein Nachteil der Speicherung des CRC-Wertes besteht allerdings darin, dass sich mit seiner Hilfe unabhängig von dem verwendeten Verschlüsselungsalgorithmus der unverschlüsselte Inhalt sehr kleinen Dateien (bis maximal vier Byte) feststellen lässt.
Aus diesem Grund wird bei der neuen AE-2-Verschlüsselungsmethode im CRC-Feld des ZIP-Headers eine 0 gespeichert und anstelle des CRC-Wertes der Authentifizierungscode verwendet, um eine Beschädigung der verschlüsselten Daten in der ZIP-Datei festzustellen.
Der einzige Unterschied zwischen der AE-1- und der AE-2-Methode besteht darin, dass bei der AE-2-Methode im ZIP-Dateiheader anstelle des CRC-Wertes eine 0 gespeichert und die Vendor-Version im AES-Extradatenfeld nicht wie bei der AE-1-Methode mit 0x0001 sondern mit 0x0002 angegeben wird.
ZIP-Dienstprogramme, die das AE-2-Format unterstützen, müssen in der Lage sein, Dateien im AE-1-Format zu lesen, und beim Entschlüsseln/Extrahieren von Dateien im AE-1-Format prüfen, ob ihr tatsächlicher CRC-Wert mit dem im CRC-Feld gespeicherten Wert übereinstimmt.
Die Beschreibung des Verfahrens zur Schlüsselgenerierung wurde aktualisiert, um auf eine durch die Verwendung von HMAC-SHA1 als Pseudozufallsfunktion bedingte Einschränkung hinzuweisen: Die HMAC-SHA1-Funktion erzeugt ein 160-Bit-Ergebnis, sodass die Größe des Suchbereichs für den Schlüssel bei Verwendung der 192-Bit- oder 256-Bit-AES-Verschlüsselung unabhängig von dem angegebenen Kennwort mit großer Wahrscheinlichkeit nicht den theoretischen Maximalwert von 192 bzw. 256 Bit erreicht, sondern eher bei dem durch die Funktion garantierten Wert von 160 Bit liegen wird. Erläuterungen hierzu finden Sie in Abschnitt B.1.1 der RFC2898-Spezifikation.
VII. Anmeldung für die Mailingliste "Developer Information"
Sie können Sie sich hier in die AES-Mailingliste eintragen.
Diese Mailingliste soll dazu dienen, die Teilnehmer auf wesentliche Änderungen in den Informationen zur AES-Verschlüsselung auf der WinZip-Website hinzuweisen.
Dokumentversion: 1.04
Zuletzt geändert: 30. Januar 30, 2009
Copyright© 2003-2009 Corel Corporation.
Alle Rechte vorbehalten
