You type a password into an archive tool and, a moment later, a file opens. Between those two events sits a short chain of steps that decides how strong the protection is and how a program can tell a right password from a wrong one. That chain is how ZIP password protection works, and following it from the typed password to the unlocked file shows exactly where the strength comes from.

A ZIP password never encrypts anything directly. The tool turns it into key material, either by seeding ZipCrypto’s three internal keys or by running PBKDF2 for WinZip AES. That key encrypts each file’s compressed bytes. Small stored values, a check byte or a verification value, let a reader reject wrong passwords cheaply before a confirmation step accepts the right one.

From password to key

Both schemes begin with the same input, the bytes of your password (UTF-8 in modern tools). What happens to those bytes next is where they part ways.

ZipCrypto: three keys, no stretching

ZipCrypto, the traditional PKWARE scheme, keeps its entire state in three 32-bit keys. They start at fixed constants, and every byte of the password updates them in turn: the first key goes through a CRC-32 table update with the password byte, the second absorbs the low byte of the first and is multiplied by a constant, and the third goes through a CRC-32 update with the high byte of the second. That is the whole key derivation.

There is no salt and no stretching. Two archives locked with the same password start from identical key state, and one candidate costs only a handful of arithmetic operations to test. The known-plaintext weaknesses that follow from this design are covered in the ZipCrypto explainer.

WinZip AES: PBKDF2 with a salt per entry

WinZip AES treats the password as the input to a deliberately slow function. A tool first reads a strength byte from the entry’s extra field: 1 means AES-128, 2 means AES-192, and 3 means AES-256. That byte fixes the key length at 16, 24, or 32 bytes and the salt length at 8, 12, or 16 bytes.

The tool then runs PBKDF2-HMAC-SHA1 for 1000 iterations over the password and a random salt stored with that entry. The output is split into three pieces: the AES encryption key, a separate authentication key of the same length, and a 2-byte password verification value. Because each entry carries its own salt, the same password yields different keys in different entries, so precomputed tables do not help. PBKDF2 repeats the 1000 iterations for every 20-byte block of key material, so a single guess costs, on purpose, between two thousand HMAC-SHA1 computations (AES-128) and four thousand (AES-256), three thousand for AES-192. The WinZip AES page covers the CTR-mode encryption itself and the AE-1 and AE-2 variants.

How a tool knows the password is right

Decrypting and decompressing a whole file for every candidate would be wasteful, so both formats store a small value that a reader can check first. That check is a filter, not proof. A survivor then goes through a full confirmation test. One entry is enough for this; ZipRecover prefers the smallest encrypted entry large enough to confirm a password decisively (among entries up to 256 MB compressed), which keeps each confirmation cheap. If every testable entry is a ZipCrypto file under 4 bytes, the result says the password passed only a quick check. If the only testable entry uses a compression method other than Store or Deflate, the tool can compare only the decrypted length, which the right password usually fails too, so a search usually ends without a match. If every encrypted entry is over 256 MB compressed, the tool reports an error instead of searching.

Scheme Fast first check Confirmation
ZipCrypto Decrypt the 12-byte encryption header and compare its last byte with a known check byte (the high byte of the stored CRC-32, or of the modification time when a data descriptor is used): about a 1 in 256 filter Decrypt the rest of the entry, inflate it, and compare the result’s CRC-32 and size with the values in the central directory
WinZip AES Compare the 2-byte verification value produced by PBKDF2 with the one stored right after the salt: about a 1 in 65,536 filter Recompute HMAC-SHA1 over the ciphertext with the authentication key and compare the first 10 bytes with the stored authentication code

The two filters are not equal. About 1 wrong password in 256 slips past the ZipCrypto check byte, and the decrypt-and-CRC step has to catch it; that step is a checksum rather than a cryptographic proof, although a wrong password that also inflates cleanly to the right size and CRC-32 is extremely unlikely on real files. For AES, about 1 wrong password in 65,536 survives the verification value, and the HMAC-SHA1 step behind it is cryptographically definitive: a confirmed AES password is never a false positive.

Notice where the cost lands. In ZipCrypto both stages are cheap. In AES the expensive part, PBKDF2, runs before the filter, so the filter only saves the HMAC, and the scheme can afford to make every guess slow.

What this means for a forgotten password

No step in this chain can be skipped. An archive cannot be asked for its password; a tool can only propose candidates and run each one through the steps above. Recovery therefore depends on how large a space you need to search and how fast each candidate can be tested.

An illustrative calculation shows the scale. Take a 12-character password drawn from upper and lower case letters and digits: 62^12, about 3.2 × 10^21 candidates. At the single-core AES-256 rate the site measured with its proof script, about 640 guesses per second, exhausting that space takes 3.2 × 10^21 ÷ 640, about 5 × 10^18 seconds, or roughly 1.6 × 10^11 years (160 billion years). Even at the ZipCrypto rate measured the same way, about 240,000 guesses per second, the same space takes on the order of 4 × 10^8 years. Both figures are modeled from those measured rates, not measured on any specific file, and adding cores divides them only linearly.

Now shrink the space with what you remember. If you know the password was six lowercase letters, that is 26^6, about 309 million candidates, which the same 640 per second covers in roughly 5.6 days on one core, or about 17 hours across eight worker threads (again illustrative). A known prefix, a remembered length, or a personal wordlist cuts the search far more than faster hardware does. The guide to how long ZIP password recovery takes works through these rates in more detail.

Everything above concerns the contents of each entry. The names, sizes, and timestamps in the central directory stay readable in a standard encrypted ZIP; the guide to what an encrypted ZIP file protects covers that container view and how to recognize the scheme in use.

If the archive is yours and the password is gone, write down what you remember about its shape first, then run a private, in-browser recovery of your ZIP password. The tool reads the strength byte, prefers the smallest encrypted entry large enough to confirm a password decisively (among entries up to 256 MB compressed), and applies exactly the filter-then-confirm chain described here, on your device only.

Sources