ZIP Extractor Encryption (ZEE)

ZIP Extractor Encryption (ZEE) Specification (PDF, Version 1.0.1 FINAL)

Officially assigned by PKWARE. PKWARE, which maintains the ZIP file format specification, assigned ZIP compression method 91 and extra-field Header ID 0x9101 to ZIP Extractor Encryption.

ZIP Extractor Encryption (ZEE) uses ZIP compression method 91 for a family of password-based encryption suites, specified and maintained by Visware LLC. Its first suite, ZEE-1, is defined by one specification, authored by Visware LLC Technical Staff. Its main themes:

• Authenticated encryption of every file. AES-256-CTR encrypts each file, and a 128-bit HMAC-SHA-256 tag authenticates it. Readers verify the tag before they accept the contents.
• One password derivation, independent keys. A new archive stretches the password once with PBKDF2-HMAC-SHA-256 at 1,000,000 iterations. HKDF then expands that root into separate encryption and authentication keys for each file, selected by a fresh random nonce.
• Optional metadata protection. In protected mode, an encrypted central directory (ZECD) encrypts and authenticates file names and other directory metadata, and binds each record to its file. Public mode keeps an ordinary directory that can be listed without a password.
• ZIP compression method 91. Following the WinZip AES pattern, method 91 identifies ZEE encryption, while extra field 0x9101 carries the actual compression method, so every file stays an independent ZIP entry, with ZIP64 and streamed writing supported.

File sizes and the archive comment remain public in both modes. The overview below introduces the format. The companion Implementer's Guide provides byte layouts, an ordered reading procedure and a worked archive; the full specification remains the normative reference. Both documents are Version 1.0.1 FINAL and describe the same ZEE-1 wire format as the 1.0.1 drafts. ZIP Extractor supports creating ZEE archives through its Enhanced Encryption option, available in production since October 31, 2026.

The 0x9101 extra field

One 0x9101 field appears in each ZEE regular file's local header and central record, with byte-identical contents. Integers are little-endian (APPNOTE 4.3.3).

Canonical DEFLATE example: 01 91 08 00 5a 45 01 00 08 00 00 00. Parsing checks bounds, signature, SuiteID, then exact size for the recognized suite. An unknown suite is unsupported; a missing, duplicate or malformed field is malformed. The complete 12 bytes are authenticated by the file tag.

SuiteID registry

A SuiteID selects one complete layout, key schedule, cipher, authentication and permitted-method contract. Published incompatible changes require a new SuiteID. ZIP Extractor maintains the suite registry.

ZEE-1 cryptography

• Passwords are nonempty strict UTF-8 of the exact Unicode scalar sequence, without normalization. New passwords additionally exclude Unicode General_Category Cc; existing credentials are used unchanged.
• A 16-byte random root salt and PBKDF2-HMAC-SHA-256 at exactly 1,000,000 iterations produce a 32-byte root. A new single-password archive must use one root for its newly encrypted files and ZECD object; copied entries may retain other root contexts or passwords.
• Every new encryption draws a fresh random 16-byte object nonce. HKDF-Expand-SHA-256 uses "ZEE-1/aes" || nonce, "ZEE-1/mac" || nonce and "ZEE-1/verify" || nonce to produce 32, 32 and 2 bytes. Directory labels are ZEE-1/dir/aes, ZEE-1/dir/mac and ZEE-1/dir/verify instead. The PBKDF2 root is used directly as the expansion key; there is no HKDF-Extract. Labels are exact ASCII followed by the raw nonce bytes, with no separator or terminator.
• AES-256-CTR uses a big-endian 128-bit counter starting at 1 under each object's encryption key. The nonce selects keys; it is not that counter.
• File authentication is the first 16 bytes of HMAC-SHA-256 over "ZEE-1/tag" || modeByte || descriptor12 || ciphertext. Mode 00 means public directory; 01 means ZECD. No mode field is stored. An unchanged protected payload cannot validate as a public-mode file after ZECD is stripped.
• File payload is rootSalt16 | nonce16 | verifier2 | AES-CTR(compressedStream[S] || CRC32LE[4]) | tag16. One continuous counter stream encrypts the compressed bytes and CRC. Ciphertext length is C = S + 4, payload length is P = S + 54, and the tag covers all ciphertext. The ciphertext bound is C <= 2^61 - 87. Readers separate the last four decrypted bytes before giving only S bytes to the codec. The two-byte verifier is an early-rejection hint, never authentication.
• ZECD has a 16-byte header: signature ZECD, uint16 version 1, uint16 suite 1 and uint64 ciphertext length C. It carries rootSalt16, nonce16, verifier2, ciphertext and tag16, with no CRC trailer. Total record size is 66 + C. Its MAC input is "ZEE-1/dir/tag" || header16 || ciphertext, with C <= 2^61 - 94. There is no mode byte in the directory MAC and no comment input. Directory plaintext is the uncompressed central-directory records alone. Verify the directory MAC before decrypting or parsing it. Each protected file record supplies an expected tag through ZEAC; compare it before file- key work, then verify the actual file MAC before accepting file contents.

ZIP and directory conventions

• Permitted actual methods are STORE, DEFLATE, Deflate64, BZIP2, LZMA with end-of-stream marker and Zstandard. Streams are self-contained. Historical Zstandard method 20 is accepted and preserved as specified by ZEE.
• Every ZEE-1 regular file, including an empty file, has full authentication. A canonical empty STORE payload is 54 bytes; shorter file payloads are malformed. Directory entries use method 0 with no encrypted payload. An empty protected archive retains ZECD; an empty public archive is ordinary ZIP without an encryption claim.
• Logical ZEE-1 file records set bits 0 and 11, clear bits 6 and 13, and may set bit 3 for a data descriptor. Public local headers follow those flags. Protected regular-file local headers set only bit 13 and, optionally, bit 3; bit 0 is clear. They retain method 91 and the ZEE descriptor while masking metadata. Known-size headers expose payload size; streamed headers carry placeholders. Individual file sizes are not promised private in either form.
• Readers support signed 16-byte classic and 24-byte ZIP64 data descriptors; writers may omit them. They follow the complete file tag and do not count in payload size. Public values are (CRC=0, P, U); protected values are all zero. ZIP64 size reservation determines width, not an offset-only ZIP64 field. Reserved size forms persist even if the final sizes fit.
• All method-91 local, central and data-descriptor CRC fields are zero in both modes. Readers reject nonzero values, including in normal local-header checks and recovery; those fields never supply an expected CRC. The encrypted trailer is the sole expected CRC, checked against the fully decoded plaintext before extracted contents are accepted. Authentication, complete stream decoding and decoded-size checks also remain mandatory for extraction. A matching CRC never excuses a failed MAC.
• Names and per-file comments written under the ZEE profile use strict UTF-8, as does newly supplied archive-comment text. Unrelated public legacy entries retain their encoding rules; unchanged archive-comment bytes may be preserved. Version needed is 51 or the higher value the actual method requires; recognition does not use it.
• Recognition at the resolved directory offset precedes generic directory parsing or version-based decryption dispatch. A recognized ZECD failure never falls back to public-directory interpretation. Full readers support both forms and parse the complete protected directory, not just the public entry count.
• Closing records are adjacent and the declared comment ends at EOF. Writers emit compact archives from offset 0. Readers add no blanket ban on an earlier prefix or gap. One archive file; no spanning.
• Same-mode pass-through preserves file payloads. Changing modes requires file keys, original-MAC verification and new tags; public-to-protected conversion must also establish the actual uncompressed sizes through authenticated decoding unless a trusted source already supplies those facts. Re-encryption requires original-MAC verification as well. Password removal verifies the original MAC and any protected directory/ZEAC association, strips the framing and CRC trailer, and may keep the unchanged compressed stream without decoding. It writes the authenticated expected trailer CRC into ordinary ZIP records, without silently repairing an incorrect value. This is not a contents test and does not establish public size claims. Extraction, content testing, recovery and public-to-protected conversion retain their full decoding and applicable size/CRC checks. A directory password alone may not unlock imported files.
• Basic local recovery may authenticate surviving content when framing gives a reliable boundary; it cannot reconstruct authenticated names, membership or a missing directory. A surviving file carries its own encrypted CRC check in either mode. Streamed entries may have weaker recovery.

Vendor extra field and comment

Each Header ID 0x455A field contains one four-byte ASCII tag and its body. Multiple fields with different tags may coexist in the same ZIP record. ZEXT is an optional producer marker; ZEAC contains a 16-byte expected file tag and appears exactly once in each protected regular-file central record. ZECD itself is an archive-level record, not an extra field.

The archive comment is public and unauthenticated in both modes. When shown, it is identified as unverified, including after unlock. Its bytes do not affect file or directory authentication; ordinary ZIP framing bounds still apply. There is no archive-comment authentication record. Public writers omit ZEAC and public readers ignore any copies as unknown extras, without attributing authentication to them.

ZIP Extractor Encryption (ZEE) Implementer's Guide (PDF, Version 1.0.1 FINAL)

ZIP Extractor Encryption (ZEE) Specification (PDF, Version 1.0.1 FINAL)