A password is not a lock on the whole archive
A password-protected ZIP is easy to treat like a locked box: whoever holds the file cannot see inside without the key. The format is more fragmented than that. A ZIP is a directory first, then a list of files. The encryption flag sits on each file’s local header and central-directory entry. It does not sit on “the entire .zip file.” Setting a password only means at least one compressed data stream was wrapped with some algorithm. It does not mean the directory is unreadable, and it does not mean every entry used the same algorithm or the same passphrase.
Payroll workbooks, ID scans, SSH private keys, database dumps, and unredacted customer sheets are all content that should not leave extra cleartext clues outside the folder you are working in. The question is not “is this zipper clever.” It is “did this pack hand over a clear filename, a clear entry, or a weak encrypted stream that should have stayed on this disk.” The previous note covered a related handoff: an unencrypted file dropped into a drive can still be opened by the provider, a sync client, and a content hash. Zipping with a password first only changes the question from “can the cloud see the file” to “which layer did this container actually lock.”
This note stays with PKWARE’s APPNOTE.TXT 6.3.10 (1 November 2022), WinZip AES specifications AE-1 / AE-2, and 7-Zip’s description of AES-256 in the 7z format, because those documents write the layers in language you can check against a local listing. Enterprise policy, a web “encrypt zip” page, and an older UI can add another layer. When you change tools, read that version’s encryption options and look at Method again. Do not paste the ZipCrypto sentences below onto an archive that already selected AES-256 or turned on filename encryption.
ZipCrypto, AES extras, and filename encryption are three layers
Hearing “is the ZIP encrypted” as a yes-or-no question drops at least three layers. The first is traditional PKWARE encryption—the method UIs often label ZipCrypto or Zip 2.0. APPNOTE section 6 keeps the object narrow: PKZIP encrypts the compressed data stream. Each encrypted file prepends a 12-byte encryption header. Three 32-bit keys start from the passphrase, then update with the same CRC-32 ZIP already uses. The extension is still .zip. File Explorer or an old extractor will often show a password prompt. Compatibility is good. Strength is a separate question.
The second layer is AES added later inside the same ZIP container. WinZip leaves the base structure alone and adds one extra: the compression method becomes decimal 99, and both the local header and the central directory carry an 11-byte extra field 0x9901 whose vendor ID is the ASCII letters AE. Strength bytes 0x01 / 0x02 / 0x03 mean 128-, 192-, and 256-bit keys. The real method (Deflate’s 8, for example) moves into that extra field. An old tool that does not understand AES usually reports “unsupported compression method 99” instead of treating ciphertext as plaintext. This layer protects file contents. By default it does not rewrite filenames in the central directory as ciphertext.
The third layer is “cover the directory as well.” ZIP Strong Encryption writes central-directory encryption as an option and needs extra general-purpose flags such as bit 6 and bit 13. Traditional ZipCrypto does not have that layer. The 7z format takes another path. 7-Zip’s format page says it uses AES-256, derives the key from the passphrase with a SHA-256-based function, and uses a large iteration count to raise the cost of exhaustive search. The command-line switch -mhe=on encrypts filenames. Leave that off and a listing can still show names even when the contents use AES.
| Layer | What it usually locks | What can still stay visible | How to spot it |
|---|---|---|---|
| ZipCrypto / traditional PKWARE | That file’s compressed data stream | Filenames, unencrypted entries, archive layout | 7z l -slt Method contains ZipCrypto |
| WinZip AES (AE-1 / AE-2) | That file’s contents (AES + HMAC) | Filenames; other unencrypted entries in the same archive | Compression method 99, extra field 0x9901, Method contains AES- |
| 7z + encrypt filenames | Contents and the directory header | Names can still list first if -mhe=on is off |
7-Zip’s “Encrypt file names” box, or -mhe=on |
A product page or a right-click menu that says “AES-256” answers the content algorithm. It does not answer whether filenames sit in a clear header, or whether some entries have no password at all. Check Method and the file list first, then worry about passphrase length.
ZipCrypto: the spec itself calls it weak
Traditional encryption is not a rumor that “people say it is weak.” The format owner already downgraded it. APPNOTE 6.0.1 says this form is considered weak by today’s standards and recommends it only for low security needs, or for compatibility with older ZIP programs. The same section writes the skeleton: the keys start as the 32-bit integers 305419896, 591751049, and 878082192; update_keys runs CRC-32 on each passphrase byte; a 12-byte encryption header at the start of the data area keeps stirring the keys; the last one or two header bytes are checked against the high CRC bits to decide whether the passphrase looks right. That is a stream cipher. It is not an authenticated block mode such as AES-GCM.
The spec also says the 12-byte header exists to “render a plaintext attack on the data ineffective.” Public research took another path. In 1994 Eli Biham and Paul C. Kocher published A Known Plaintext Attack on the PKZIP Stream Cipher, showing that a stretch of known plaintext can recover internal state. Michael Stay’s 2002 note ZIP Attacks with Reduced Known Plaintext lowered the amount of plaintext required. Archives often ship predictable prefixes—%PDF, a fixed Office header, an XML declaration, a PNG signature—because those are file formats, not secrets. Attack steps are out of scope here. The point that belongs in a conclusion is: the weakness is the algorithm, not “your password is only six characters.” A longer passphrase does not rewrite “the spec calls traditional encryption weak, and a known-plaintext research line exists.”
Compatibility explains why the method is still around. Windows File Explorer can create and open ordinary ZIP files, but it has no native “put a password on this ZIP” UI. An independent advisor on Microsoft Q&A wrote that you need a third-party tool such as 7-Zip to set a password, and that Explorer can still prompt for ZipCrypto archives those tools produce. Plenty of software therefore leaves ZipCrypto as the default so the other side can double-click. You get “they do not have to install anything.” You pay the weak encryption the spec already admits. 7-Zip can write a ZIP with AES-256 instead. After that change, a system extractor that only understands ZipCrypto may refuse to open the file. That is a trade-off between compatibility and strength, not “both menus say encryption, so they are the same.”
Filenames, CRCs, and unencrypted entries stay in the clear
Even after the content layer moves to AES, a ZIP is still, by default, a container you can list. FileName in the local header and the central directory is a cleartext field. General purpose bit 0 only means this entry’s data stream is encrypted. Bit 11 means the name is UTF-8. It does not mean the name is encrypted. In 2004 Tadayoshi Kohno’s analysis of the WinZip encryption scheme wrote three format facts in plain language: metadata of encrypted files leaks, filenames are not authenticated, and one archive may hold encrypted and unencrypted files at the same time. Those are allowed shapes of the container, not implementation bugs.
WinZip’s own AES note writes mixed archives as a formal permission. There is no requirement that every file in a ZIP be encrypted, and no requirement that encrypted files share one method or one passphrase. One archive may combine unencrypted files with Zip 2.0, AES-128, AES-192, and AES-256 in any mix. Folder entries are even recommended not to be encrypted, to save space. The practical result: you drop payroll-2026-09.xlsx and readme.txt into the same pack, and only the spreadsheet may ask for a password. The note and the directory names are readable by anyone who holds the file. Recipients, mail gateways, drive previews, and sync clients often see that listing first—not the cells after a successful extract.
Clear headers also carry size and checksums. WinZip writes that AE-1 stores the CRC of the unencrypted contents in the ZIP header, while AE-2 stores the CRC as 0 and relies on a 10-byte authentication code for integrity. The FAQ states the reason: for a file of four bytes or fewer, the CRC itself can help infer the original, whatever encryption you used. From WinZip 11 onward, most files go back to AE-1 for an extra integrity check, but files whose uncompressed size is under 20 bytes, and BZIP2 streams that already carry their own check, still use AE-2 and store no CRC. Key derivation is PBKDF2 (RFC 2898) with 1,000 iterations; the pseudo-random function is HMAC-SHA1. The spec also notes that HMAC-SHA1 outputs 160 bits, so the effective search space for 192- or 256-bit AES cannot be read as the theoretical key length. You do not need a “crack” to check these numbers. They are already in the public specification.
Check a password-protected ZIP without extracting
A slogan that says “I set a password, so it is safe” cannot prove itself. Split the check into steps you can finish on this machine. Each step answers one question. Do not run the experiment on a real payroll sheet, a certificate, or a private key.
Do not pack an ID scan you still use, a production key, or a live employee table “just to see what it looks like.” Prepare a disposable canary—for example a file named canary-payroll-20260905.txt whose body is one one-time marker. You are checking the directory and Method, not compressing the real file again.
- Write a canary text file whose name deliberately looks like a business document, such as
canary-payroll-20260905.txt. If you need a random passphrase, draw 6–128 characters from the password generator (default 16; under 8 is flagged as weaker). Treat that string only as the archive password, not as a new login password. - Build a ZIP the way you usually send files: some tools default to ZipCrypto; others make you pick AES-256. Do not rename the file to “hide” the topic. Build a second 7z archive, once with filename encryption on and once with it off, so you can compare.
- Do not enter the passphrase yet. Open the ZIP in 7-Zip, or run
7z l -slt canary.zipin a terminal. See whether the listing already showscanary-payroll-20260905.txt. Then find theMethod =line:ZipCryptois traditional encryption;AES-256is the content-layer AES. You can read both without extracting the body, which means they do not sit behind “you must type the password first.” - List the 7z archive the same way. With filename encryption off, the name often still appears. With
-mhe=on, the canary name should not appear until you enter the passphrase. That is a check for the third layer, not a claim that “7z is automatically more mysterious than ZIP.” The difference is whether the directory header is covered. - Drop the canary archive into the drive or mail draft you actually use (do not send it to anyone). See whether the preview or the web UI lists inner filenames. The previous note covered instant upload and preview on unencrypted files; here, even if the contents are locked, the directory names may still be indexed. When you finish, delete the canary archive and the source file, and check the recycle bin.
The first half of a local-crypto check—whether this tab handed plaintext to a server—is a different question from How to verify browser encryption: prove plaintext never left. A zipper almost always has to read the original on this machine in order to pack it. This note asks what remains after packing, outside the ciphertext stream. If the canary name appears in 7z l -slt or a drive preview before you type a password, the trust boundary is larger than “the other person does not have the password.” If Method is still ZipCrypto, you bought compatibility, not strong encryption in the sense the spec uses.
Separate whole-file ciphertext from an archive password
If what you want is “turn this file into ciphertext on this device, then decide whether mail or a drive carries it,” you do not need to register, and you do not hand the file to MakePwd. Open File Encryption Box. The current tab encrypts in chunks with AES-256-GCM and lets you download .lock or .enc. The passphrase is stretched with PBKDF2-HMAC-SHA256 and 100,000 iterations; each file gets its own salt. One file can be up to 5 GB. The file, the passphrase, and the plaintext are not uploaded as business data. Every tool opens with no account, and there is no password vault that stores the passphrase for you.
File Encryption Box answers “did these bytes become ciphertext before they left the browser.” It does not answer “does a ZIP lock filenames by default.” You choose the download name, so you do not have to ship something like payroll-2026.xlsx.zip that advertises the topic. The .lock header can still carry the original filename; if that name is sensitive, rename the file before you encrypt. Ciphertext can travel through a drive or mail. Send the passphrase on another channel—for example Burn-Link: the key sits in the URL # fragment, it is not sent to the server with HTTP, create and read are both public, and the server stores only ciphertext. When you need a random passphrase, draw 6–128 characters from the Password Generator and copy it on that page only. What a provider can still see after an unencrypted upload is the previous note. This one only draws a line around what a password-protected ZIP can still leave behind.
FAQ
If a ZIP has a password, is the whole archive encrypted?
No. PKWARE APPNOTE puts the encryption flag on each file’s general purpose bit 0. That bit covers that entry’s compressed data stream, not the container. Filenames sit in the local header and the central directory. WinZip’s AES note says one ZIP may mix unencrypted entries with Zip 2.0, AES-128, AES-192, and AES-256, and the passwords may differ.
What is the difference between ZipCrypto and AES-256 ZIP?
ZipCrypto is traditional PKWARE encryption in APPNOTE section 6: three 32-bit keys, a 12-byte encryption header, and CRC-32 key updates. The spec itself calls it weak by today’s standards and recommends it only for low security or old ZIP programs. WinZip AES uses extra field 0x9901, compression method 99, a salt, a password verifier, and an HMAC-SHA1 authentication code. Both still use .zip, so you have to read Method, not the extension.
Can someone see the file list without the password?
Usually yes, for a traditional ZIP and for a 7z archive that did not turn on filename encryption. 7-Zip’s 7z l -slt lists names and Method without extracting plaintext. The 7z format can encrypt filenames with -mhe=on; that is the layer that covers the directory header. Windows Explorer has no native UI to put a password on a ZIP.
Is a passworded ZIP the same as MakePwd File Encryption Box?
No. An archive password answers which ZIP encryption that container used. File Encryption Box encrypts the whole file in this tab with AES-256-GCM, writes .lock / .enc, caps one file at 5 GB, does not upload the file or passphrase, and opens with no account. Send the passphrase on another channel, for example a Burn-Link # fragment.
Three things to remember before the next archive
First, “I set a password” only means at least one file’s data stream was wrapped with some ZIP encryption. It does not mean the directory is unreadable, and it does not mean every entry is encrypted. Second, ZipCrypto (the spec calls it weak; a known-plaintext research line exists), WinZip AES (stronger on contents; filenames stay in the clear by default), and 7z filename encryption are three different boundaries. An extension of .zip or .7z does not tell you which layer you are on. Third, check Method and the names that appear before a passphrase with a one-time canary and 7z l -slt. Do not run that check on a real spreadsheet.
If the next question is what a provider can still see after an unencrypted file enters a drive, read What a cloud provider, sync client, and content hash can still see after you upload an unencrypted file. When the encrypt step itself has to prove plaintext never left this device, read How to verify browser encryption: prove plaintext never left. When the passphrase has to travel separately and you do not want it in the mail body, read Why a URL hash fragment is a fit place for a key—and when that protection fails. This note only draws a line you can write into a conclusion: after you send a password-protected ZIP, what default encryption, filenames, and unencrypted entries can still leave behind.