Ok,
I found out that is is in fact a valid compression method 99 and not just
bullshit =D
http://www.winzip.com/p_aes_info.htm
AES Encryption Information:
Encryption Specification AE-2
NOTE: WinZip® users do not need to read or understand the information
contained on this page. It is intended for developers of Zip file utilities.
The AE-2 encryption specification described here involves a minor change to
the AE-1 encryption specification covered in the original May, 2003 version
of this document. The recent changes to this document are summarized in the
Change History section below.
This document describes the file format that WinZip uses to create
AES-encrypted Zip files. The AE-2 encryption specification was introduced in
WinZip 9.0 Beta 3, released in January, 2004.
From time to time we may update the information provided here, for example
to document any changes to the file formats, or to add additional notes or
implementation tips. If you would like to receive e-mail announcements of
any substantive changes we make to this document, you can sign up below for
our AES Encryption Information mailing list.
Without compromising the basic Zip file format, WinZip Computing has
extended the format specification to support AES encryption, and this
document fully describes the format extension. Additionally, we are
providing information about a no-cost third-party source for the actual AES
encryption code--the same code that is used by WinZip. We believe that use
of the free encryption code and of this specification will make it easy for
all developers to add compatible advanced encryption to their Zip file
utilities.
This document is not a tutorial on encryption or Zip file structure. While
we have attempted to provide the necessary details of the current AES
encryption specification (known as "AE-2"), developers and other interested
third parties will need to have or obtain an understanding of basic
encryption concepts, Zip file format, etc.
Developers should also review AES Coding Tips page.
WinZip Computing, Inc. makes no warranties regarding the information
provided in this document. In particular, WinZip Computing, Inc. does not
represent or warrant that the information provided here is free from errors
or is suitable for any particular use, or that the file formats described
here will be supported in future versions of WinZip. You should test and
validate all code and techniques in accordance with good programming
practice.
----------------------------------------------------------------------------
----
Contents
Encryption services
Zip file format
Base format reference
Compression method and encryption flag
CRC value
AES extra data field
Encrypted file storage format
File format
Salt value
Password verification value
Encrypted file data
Authentication code
Notes
Non-files and zero-length files
"Mixed" Zip files
Key generation
FAQs
Change history
Mailing list signup
----------------------------------------------------------------------------
----
I. Encryption services
To perform AES encryption and decryption, WinZip uses AES functions written
by Dr. Brian Gladman. The source code for these functions is available in
C/C++ and Pentium family assembler for anyone to use under an open source
BSD or GPL license from the AES project page on Dr. Gladman's web site. The
AES Coding Tips page also has some information on the use of these
functions. WinZip Computing thanks Dr. Gladman for making his AES functions
available to anyone under liberal license terms.
Dr. Gladman's encryption functions are portable to a number of operating
systems and can be static linked into your applications, so there are no
operating system version or library dependencies. In particular, the
functions do not require Microsoft's Cryptography API.
General information on the AES standard and the encryption algorithm (also
known as Rijndael) is readily available on the Internet. A good place to
start is http://www.nist.gov/public_affairs/releases/g00-176.htm.
II. Zip file format
Base format reference
AES-encrypted files are stored within the guidelines of the standard Zip
file format using only a new "extra data" field, a new compression method
code, and a value of 0 in the CRC field. The basic Zip file format is
otherwise unchanged.
The basic Zip file format specification used by WinZip is available via FTP
from the Info-ZIP group at
ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip.
Compression method and encryption flag
As for any encrypted file, bit 0 of the "general purpose bit flags" field
must be set to 1 in each AES-encrypted file's local header and central
directory entry.
The presence of an AES-encrypted file in a Zip file is indicated by a new
compression method code (decimal 99) in the file's local header and central
directory entry, used along with the AES extra data field described below.
There is no change in either the version made by or version needed to
extract codes.
The code for the actual compression method is stored in the AES extra data
field (see below).
CRC value
For files encrypted using the AE-2 method, the standard Zip CRC value is not
used, and a 0 must be stored in this field. Corrupted data is instead
detected via the authentication code field.
Files encrypted using the AE-1 method do include the standard Zip CRC value.
This, along with the fact that the vendor version stored in the AES extra
data field is 0x0001 for AE-1 and 0x0002 for AE2, is the only difference
between the AE-1 and AE-2 formats.
NOTE: Zip utilities that support the AE-2 format are required to be able to
read files that were created in the AE-1 format, and during
decryption/extraction of files in AE-1 format should verify that the file's
CRC matches the value stored in the CRC field.
AES extra data field
A file encrypted with AES encryption will have a special "extra data" field
associated with it. This extra data field is stored in both the local header
and central directory entry for the file.
Note: see the Zip file format document referenced above for general
information on the format and use of extra data fields.
The extra data header ID for AES encryption is 0x9901. The fields are all
stored in Intel low-byte/high-byte order. The extra data field currently has
a length of 11: seven data bytes plus two bytes for the header ID and two
bytes for the data size. Therefore, the extra data overhead for each file in
the archive is 22 bytes (11 bytes in the central header plus 11 bytes in the
local header).
The format of the data in the AES extra data field is as follows. See the
notes below for additional information.
Offset Size
(bytes) Content
0 2 Extra field header ID (0x9901)
2 2 Data size (currently 7, but subject to possible increase in the future)
4 2 Integer version number specific to the zip vendor
6 2 2-character vendor ID
8 1 Integer mode value indicating AES encryption strength
9 2 The actual compression method used to compress the file
Notes
Data size: this value is currently 7, but because it is possible that the
AE-2 specification will be modified in the future to store additional data
in this extra field, vendors should not assume that it will always remain 7.
Vendor ID: the AES extra data field is designed to be extensible so that
vendors can add their own variations on non-Zip 2.0 encryption. Vendors who
want to add a new variation are required to change the two vendor ID bytes
to something unique. For example, an update specific to WinZip would use the
two-letter vendor ID of "WZ". Each vendor may then use the version to
indicate newer versions specific to their vendor ID.
For the non-vendor-specific version of the AES specification (known as
"AE-2"), a generic vendor ID of "AE" (AES Encryption) is used.
Vendor version: the vendor version for AE-2 is 0x0002.
Zip utilities that support AE-2 must also be able to process files that are
encrypted in AE-1 format, which use 0x0001 as the vendor version. The
handling of the CRC value is the only difference between the AE-1 and AE-2
formats.
Encryption strength: the mode values (encryption strength) for AE-2 are:
Value Strength
0x01 128-bit encryption key
0x02 192-bit encryption key
0x03 256-bit encryption key
The AE-2 specification supports only 128-, 192-, and 256-bit encryption
keys. No other key lengths are permitted.
(Note: the current version of WinZip does not support encrypting files using
192-bit keys. The AE-2 specification, however, does provide for the use of
192-bit keys, and WinZip is able to decrypt such files.)
Compression method: the compression method is the one that would otherwise
have been stored in the local and central headers for the file. For example,
if the file is imploded, this field will contain the compression code 6.
This is needed because a compression method of 99 is used to indicate the
presence of an AES-encrypted file (see above).
III. Encrypted file storage format
File format
Additional overhead data required for decryption is stored with the
encrypted file itself (i.e., not in the headers). The actual format of the
stored file is as follows; additional information about these fields is
below. All fields are byte-aligned.
Size
(bytes) Content
Variable Salt value
2 Password verification value
Variable Encrypted file data
10 Authentication code
Note that the value in the "compressed size" fields of the local file header
and the central directory entry is the total size of all the items listed
above. In other words, it is the total size of the salt value, password
value, encrypted data, and authentication code.
Salt value
The "salt" or "salt value" is a random or pseudo-random sequence of bytes
that is combined with the encryption password to create encryption and
authentication keys. The salt is generated by the encrypting application and
is stored unencrypted with the file data.
Good cryptographic practice requires that a different salt value be used for
each of multiple files encrypted with the same password. If multiple files
are encrypted with the same password and salt, they will all start with the
same encryption key, making it much easier to crack all of the files if any
one of them is cracked. Therefore, you should make every effort to use a
unique salt value for each file.
In the AE-2 implementation, the size of the salt value depends on the length
of the encryption key, as follows:
Key size Salt size
128 bits 8 bytes
192 bits 12 bytes
256 bits 16 bytes
Password verification value
This two-byte value is produced as part of the process that derives the
encryption and decryption keys from the password. When encrypting, a
verification value is derived from the encryption password and stored with
the encrypted file. Before decrypting, a verification value can be derived
from the decryption password and compared to the value stored with the file,
serving as a quick check that will detect most, but not all, incorrect
passwords. There is a 1 in 65,536 chance that an incorrect password will
yield a matching verification value; therefore, a matching verification
value cannot be absolutely relied on to indicate a correct password.
Information on how to obtain the password verification value from Dr.
Gladman's encryption library can be found on the coding tips page.
This value is stored unencrypted.
Encrypted file data
Encryption is applied only to the content of files. It is performed after
compression, and not to any other associated data. The file data is
encrypted byte-for-byte using the AES encryption algorithm operating in
"CTR" mode, which means that the lengths of the compressed data and the
compressed, encrypted data are the same.
It is important for implementors to note that, although the data is
encrypted byte-for-byte, it is presented to the encryption and decryption
functions in blocks. The block size used for encryption and decryption must
be the same. To be compatible with the AE-2 specification, this block size
must be 16 bytes (although the last block may be smaller).
Authentication code
Authentication provides a high quality check that the contents of an
encrypted file have not been inadvertently changed or deliberately tampered
with since they were first encrypted. In effect, this is a super-CRC check
on the data in the file after compression and encryption. (Additionally,
authentication is essential when using CTR mode encryption because this mode
is vulnerable to several trivial attacks in its absence.)
The authentication code is derived from the output of the encryption
process. Dr. Gladman's AES code provides this service, and information about
how to obtain it is in the coding tips.
The authentication code is stored unencrypted. It is byte-aligned and
immediately follows the last byte of encrypted data.
IV. Notes
Non-files and zero-length files
To reduce Zip file size, it is recommended that non-file entries such as
folder/directory entries not be encrypted. This, however, is only a
recommendation; it is permissible to encrypt or not encrypt these entries,
as you prefer.
On the other hand, it is recommended that you do encrypt zero-length files.
The presence of both encrypted and unencrypted files in a Zip file may
trigger user warnings in some Zip file utilities, so the user experience may
be improved if all files (including zero-length files) are encrypted. Again,
however, this is only a recommendation. Zip file utilities may encrypt or
not encrypt zero-length files in accordance with the vendor's preference.
If zero-length files are encrypted, the encrypted data portion of the file
storage (see above) will be empty, but the remainder of the encryption
overhead data must be present, both in the file storage area and in the
local and central headers.
"Mixed" Zip files
There is no requirement that all files in a Zip file be encrypted or that
all files that are encrypted use the same encryption method or the same
password.
A Zip file can contain any combination of unencrypted files and files
encrypted with any of the four currently defined encryption methods (Zip
2.0, AES-128, AES-192, AES-256). Encrypted files may use the same password
or different passwords.
Key Generation
Key derivation, as used by AE-2 and as implemented in Dr. Gladman's library,
is done according to the PBKDF2 algorithm, which is described in the RFC2898
guidelines. An appropriate number of bits from the resulting hash value are
used to compose three output values: an encryption key, an authentication
key, and a password verification value. The first n bits become the
encryption key, the next n bits become the authentication key, and the last
16 bits (two bytes) become the password verification value.
As part of the process outlined in RFC 2898 a pseudo-random function must be
called; AE-2 uses the HMAC-SHA1 function, since it is a well-respected
algorithm that has been in wide use for this purpose for several years.
Note that, when used in connection with 192- or 256-bit AES encryption, the
fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the
password that you specify, the search space for the encryption key is
unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be
guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the
RFC2898 specification.
V. FAQs
Why is the compression method field used to indicate AES encryption?
As opposed to using new version made by and version needed to extract values
to signal AES encryption for a file, the new compression method is more
likely to be handled gracefully by older versions of existing Zip file
utilities. Zip file utilities typically do not attempt to extract files
compressed with unknown methods, presumably notifying the user with an
appropriate message.
How can I guarantee that the salt value is unique?
In principle, the value of the salt should be different whenever the same
password is used more than once, for the reasons described above, but this
is difficult to guarantee.
In practice, the number of bytes in the salt (as specified by AE-2) is such
that using a pseudo-random value will ensure that the probability of
duplicated salt values is very low and can be safely ignored.
Although salt values do not need to be truly random, it is important that
they be generated in a way that the probability of duplicated salt values is
not significantly higher than that which would be expected if truly random
values were being used.
One technique for generating salt values is presented in the coding tips
page.
The addition of salt values to passwords provides a number of security
benefits and makes automated password searches much more difficult.
Why is there an authentication code? What about the CRC-32?
The CRC-32 value stored in the Zip file is the CRC of the file's data before
compression and encryption. The authentication value ensures that the data
stored in the Zip file has not been altered after compression and
encryption.
The current consensus in the cryptographic community is that authentication
has strong security value because it makes a number of attacks more
difficult to engineer. For CTR mode encryption in particular, authentication
is especially important because a number of trivial attacks are possible in
its absence. Authentication is performed using HMAC-SHA1, a mature and
widely respected authentication algorithm.
The CRC-32 value has an additional drawback in that for a very small file,
such as a file of four or fewer bytes, the CRC-32 value can be used,
independent of the encryption algorithm, to help determine the unencrypted
contents of the file. Because of this, files encrypted with AE-2 use the
authentication code instead of the CRC-32 value to verify that the data of
the file has not been corrupted, and a 0 is stored in the file header
instead of the usual CRC-32 value.
How do I use the vendor ID and version fields?
If you are following the AE-2 specification as described in this document,
simply use the values indicated above: set the vendor ID to "AE" and the
vendor version to 0x0002.
If you are creating an extension to the specification such that an existing
Zip file utility implementing AE-2 would not be able to decrypt the files,
use a unique vendor ID and version number. For example, an extension created
by WinZip Computing, Inc., might use a vendor ID of "WZ" and a vendor
version of 1 (WZ-1). The next such extension might be WZ-2, etc.
Any vendor creating such an extension to the specification is strongly urged
to publish the specification in sufficient detail to allow other vendors to
duplicate the implementation.
VI. Change history
Changes made in document version 1.02, January, 2004: The introductory text
at the start of the document has been rewritten, and minor editorial and
clarifying changes have been made throughout the document. Two substantive
technical changes have been made:
AE-2 Specification
Standard Zip files store the CRC of each file's unencrypted data. This value
is used to help detect damage or other alterations to Zip files. However,
storing the CRC value has a drawback in that, for a very small file, such as
a file of four or fewer bytes, the CRC value can be used, independent of the
encryption algorithm, to help determine the unencrypted contents of the
file.
Because of this, files encrypted with the new AE-2 method store a 0 in the
CRC field of the Zip header, and use the Authentication code instead of the
CRC value to verify that the data of the file has not been corrupted.
The AE-2 method is intended to be used in new applications in place of the
AE-1 method described in the original version of this document. The only
differences between the AE-1 and AE-2 methods are the storage in AE-2 of 0
instead of the CRC in the Zip file header, and the use in the AES extra data
field of 0x0002 for AE-2 instead of 0x0001 for AE-1 as the vendor version.
Zip utilities that support the AE-2 format are required to be able to read
files that were created in the AE-1 format, and during decryption/extraction
of files in AE-1 format should verify that the file's CRC matches the value
stored in the CRC field.
Key Generation and HMAC-SHA1
The description of the key generation mechanism has been updated to point
out a limitation arising from its use of HMAC-SHA1 as the pseudo-random
function: When used in connection with 192- or 256-bit AES encryption, the
fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the
password that you specify, the search space for the encryption key is
unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be
guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the
RFC2898 specification.
VII. Mailing List Signup
We plan to use this mailing list to notify subscribers of any substantive
changes made to the AES Encryption Information pages on the WinZip web site.
* indicates required field
* E-mail address:
If you enter your e-mail address above, you will receive a message asking
you to confirm your wish to be added to the mailing list. If you don't reply
to the confirmation message, you will not be added to the list.
By subscribing to this complimentary mailing list service, you acknowledge
and agree that WinZip Computing makes no representations regarding the
completeness or accuracy of the information provided through the service,
and that this service may be discontinued, in whole or in part, with respect
to any or all subscribers at any time.
----------------------------------------------------------------------------
----
Document version: 1.02
Last modified: January 20, 2004
Copyright © 2004 WinZip Computing, Inc.
All Rights Reserved
Copyright© 2004 WinZip Computing, Inc. WinZip is a registered trademark of
WinZip Computing, Inc.
Bye,
Skybuck.
Post by Skybuck FlyingHi,
I found this tool called Info-zip Wiz's.
At first I didn't seem to provide much information... hehe.
But when opening the archive and actually selecting a file in the archive
and then choosing complete archive information and scrolling up it
provides
Post by Skybuck FlyingIt also seems that my first guess at the extra fields was correct (?) and
the compression method 99 is unknown ?! :o Maybe they used their own
compression method ;)
Here is the info from the tool ;)
Archive: F:\xxxxxxxxxxxx\xxxxxx\xxxxxxxx.zip 40450 bytes 2 files
-------------------------------
Actual offset of end-of-central-dir record: 40428 (00009DECh)
Expected offset of end-of-central-dir record: 40428 (00009DECh)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 2 entries. The central directory is 138
(0000008Ah) bytes long, and its (expected) offset in bytes from the
beginning of the zipfile is 40290 (00009D62h).
There is no zipfile comment.
---------------------------
xxxxxxxx.dll
offset of local header from start of archive: 19454 (00004BFEh)
bytes
Post by Skybuck Flyingfile system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: unknown (99)
file security status: encrypted
extended local header: no
file last modified on (DOS date/time): 2004 Jul 26 15:08:22
32-bit CRC value (hex): 00000000
compressed size: 20783 bytes
uncompressed size: 65536 bytes
length of filename: 12 characters
length of extra field: 11 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
02 00 41 45 03 08 00.
There is no file comment.
Archive: F:\xxxxxxxxxxxx\xxxxxx\xxxxxxxx.zip 40450 bytes 2 files
-------------------------------
Actual offset of end-of-central-dir record: 40428 (00009DECh)
Expected offset of end-of-central-dir record: 40428 (00009DECh)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 2 entries. The central directory is 138
(0000008Ah) bytes long, and its (expected) offset in bytes from the
beginning of the zipfile is 40290 (00009D62h).
There is no zipfile comment.
---------------------------
xxxxxxxx.exe
offset of local header from start of archive: 0 (00000000h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: unknown (99)
file security status: encrypted
extended local header: no
file last modified on (DOS date/time): 2004 Jul 26 15:08:34
32-bit CRC value (hex): 00000000
compressed size: 19401 bytes
uncompressed size: 28160 bytes
length of filename: 12 characters
length of extra field: 11 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
02 00 41 45 03 08 00.
There is no file comment.
Bye,
Skybuck.