.ZIP File Format – Encryption

Keys

Three 32-bit keys start at fixed values and are updated with each byte. The password primes them.

key0 = 305419896     // 0x12345678
key1 = 591751049     // 0x23456789
key2 = 878082192     // 0x34567890
for each byte p of the password:
    update_keys(p)

update_keys(b):
    key0 = crc32(key0, b)
    key1 = key1 + (key0 & 0xFF)
    key1 = key1 × 134775813 + 1        // keep the low 32 bits
    key2 = crc32(key2, key1 >> 24)

crc32(crc, b):
    return (crc >> 8) ^ table[(crc ^ b) & 0xFF]

The table is the same as the one for CRC-32, but the initial and final inversions are not used here.

Each encrypted byte is XORed with a keystream byte, and the plaintext is fed back:

decrypt_byte():
    t = key2 | 2                       // use the low 16 bits
    return ((t × (t ^ 1)) >> 8) & 0xFF

decrypt(cipher):
    plain = cipher ^ decrypt_byte()
    update_keys(plain)
    return plain

The 12-byte header

Decrypt the first 12 bytes with decrypt. They are random bytes, but the last byte (or last two, before PKZIP 2.0) is a check value, to tell a wrong password at once:

• The check byte is the high byte of the member’s CRC-32.
• When flag bit 3 is set, the CRC-32 is not known when the header is written, so the check byte is the high byte of the MS-DOS time instead. Python’s zipfile does this.

A wrong password can pass this check by chance, in about 1 case in 256, so a reader must still test the CRC-32 of the output. Decrypting everything after the 12 bytes in the same way gives the compressed data.

Stored layout

The compressed size field covers all four parts. A zero-length file has no encrypted data but keeps the salt, verifier and authentication code, and WinZip recommends encrypting such files. It recommends leaving folder entries unencrypted.

Key derivation

PBKDF2 (RFC 2898) with HMAC-SHA1 and 1000 iterations, over the password and salt, produces one output split in order:

1. The AES key: 16, 24 or 32 bytes for strength 1, 2 or 3.
2. The authentication key, the same length as the AES key.
3. The 2-byte password verification value.

WinZip’s page does not state the length of the authentication key. Implementations such as libzip and minizip-ng use the AES key length.

Cipher and authentication

Data is encrypted with AES in counter mode, byte for byte, so the length does not change. Each 16-byte block is XORed with the AES of a counter. WinZip’s page does not give the counter details; implementations start at 1 and use a little-endian counter.

The authentication code is an HMAC-SHA1 of the encrypted data, using the authentication key, truncated to the first 10 bytes (80 bits). A reader should compute it over the ciphertext before trusting anything it decrypts.

AE-1 and AE-2

APPNOTE’s Appendix E covers the same system, as “AE-x”.

Decryption header

All block ciphers use CBC mode. SHA-1 is used for key derivation.

Algorithms and flags

Flags in the 0x0017 block are 0x0001 password required, 0x0002 certificates only and 0x0003 either; values above 0x0003 are reserved for certificate processing. 0x0100 means non-OAEP key wrapping (version needed at least 61) and 0x4000 that ErdData uses 3DES-168.

The 0x0017 block

Archive extra data record

Present only when certificates are used, immediately before the central directory. It holds extra blocks 0x0014, 0x0016 and 0x0019. Its size counts in the central directory size, and it is compressed and encrypted with the directory.