ZIP Password Security: ZipCrypto vs AES-256

"Password-protected ZIP" sounds like one thing. It is actually two, and the gap between them is the difference between real encryption and a speed bump that has been academically broken since 1994.

From the outside you cannot tell which one you have. Both ask for a password. Both refuse to open without it. One of them can be defeated by an attacker who never guesses your password at all.

The two schemes

The ZIP format has accumulated two different encryption methods over its lifetime, and both are still in active use:

• ZipCrypto (also called traditional PKWARE encryption) dates from the late 1980s. It is the default in some tools to this day because it is the only method every ZIP reader on earth understands. It is also the one with the problem.
• WinZip AES, normally AES-256, was added in the early 2000s. It is a proper modern cipher with no known practical break. The trade-off is compatibility: very old or very minimal ZIP readers may not open it.

That compatibility trade-off is why ZipCrypto refuses to die. Tools keep offering it, and users keep picking the option that "works everywhere" without knowing what they are giving up.

Why ZipCrypto is not really encryption any more

ZipCrypto's weakness is not a weak password problem. It is a weakness in the cipher itself, and it means the password can be bypassed rather than guessed.

Biham and Kocher published a known-plaintext attack on it in 1994. In practical terms: if an attacker can obtain, or correctly guess, a small amount of the original unencrypted content of any file in the archive, they can recover the internal keys and decrypt everything in it. They never learn your password, and they do not need to - they get the contents directly.

The catch is how easy "a small amount of known plaintext" turns out to be in practice. Archives are full of files with predictable openings. A PDF starts with %PDF-. A PNG has a fixed 8-byte signature. An Office document is a ZIP whose first entry is nearly always the same. Put a single file with a predictable header in a ZipCrypto archive and you have handed over the material for the attack. Tooling to do this is public and fast.

So the practical summary: a ZipCrypto archive protects against a colleague casually double-clicking it. It does not protect against anyone who actually wants the contents. Do not use it for anything that matters, and treat a ZipCrypto archive you receive as effectively unencrypted.

The thing almost nobody mentions: your filenames are public

Here is the detail that surprises people, and it applies to both schemes, AES included.

A ZIP file keeps an index of its contents called the central directory - the list of what is in the archive, with names, sizes, timestamps and compression details. Password protection in ZIP encrypts file contents only. The central directory stays in plaintext, because that is what lets a ZIP reader show you the file listing before you type anything.

Which means anyone holding your archive can read, without the password:

• Every filename, in full
• The size of each file, compressed and uncompressed
• Modification timestamps
• The folder structure

In a lot of real situations that is the sensitive part. Q3_redundancy_list.xlsx, offer_letter_final.docx, patient_4471_scan.dcm - the filename tells the story and the contents are almost a formality. A ZIP encrypted with AES-256 will still show all of it.

This is also, incidentally, why our own archive tools can tell you that a protected archive contains an executable before you supply the password. The listing was never secret.

If the filenames matter, use 7z instead

The 7z format solves exactly this problem: it supports encrypted headers, which puts the file listing inside the encryption boundary along with the contents. An encrypted-header 7z archive reveals nothing but its own size. ZIP has no equivalent option - it is a limitation of the container, not of any particular tool.

So the choice is straightforward once you know it exists:

• Contents are sensitive, filenames are not - password-protect a ZIP, which uses AES-256 rather than legacy ZipCrypto. Maximum compatibility for the recipient.
• Filenames are sensitive too - password-protect a 7Z instead. Header encryption is enabled, so the listing is covered as well.

If you are choosing between the archive formats more generally, RAR vs ZIP vs 7Z covers compression and compatibility rather than encryption.

Removing a password is a different job from cracking one

Worth being blunt about this, because search results for this topic are full of tools that blur the line.

Removing protection requires the password. The contents are encrypted with it; there is no way to repackage them without decrypting them first. A tool that promises to remove a password from a modern AES archive without being told the password is either running a guessing attack or describing something it cannot do.

Remove a password from a ZIP asks you for the password, and that is the honest design. It decrypts with the password you supply and hands back a plain ZIP with identical contents. The same applies to removing a 7Z password.

One genuinely useful capability there: because it uses the 7-Zip engine rather than a minimal ZIP library, it reads both ZipCrypto and AES-encrypted archives. A lot of libraries handle only the legacy scheme, which is why some tools fail on modern archives with an unhelpful error.

When removing the password is the right call

Stripping protection sounds like a downgrade, and sometimes it is the correct move:

• The archive is going somewhere already access-controlled. A password on a file inside a permissioned team drive adds friction, not security - and it guarantees someone will lose the password in six months.
• Automation cannot type. Build pipelines, importers and scheduled jobs choke on interactive password prompts. The usual workaround is to hard-code the password in a script, which is worse than not having one.
• Re-protecting properly. If an archive arrived as ZipCrypto, the only way to upgrade it is to decrypt and re-encrypt. Strip it, then protect it again with AES-256 or move it to an encrypted-header 7z.
• Long-term archiving. A password nobody remembers turns an archive into a brick. For material that must remain readable in ten years, deliberate accessibility often beats encryption you will lose the key to.

What our tools will refuse to do

Two limits worth knowing before you upload, because they are deliberate:

First, archives containing executable file types are rejected rather than unpacked - .exe, .dll, .msi, script files and similar. Password-protected archives are a classic malware delivery method precisely because the encryption hides the payload from scanners, and we are not going to be the service that strips the wrapper off one. Because the file listing is not encrypted, this check happens before extraction, so you get the answer immediately rather than after a minute of work. The message names every offending type at once so you are not rediscovering the policy one file at a time.

Second, there are size limits on what comes out: 5,000 files and 500 MB extracted. These exist because a small archive can expand into an enormous one, and a service that processes everything in memory has to bound that.

Where the password goes

Since you are typing a password into a web page, the handling matters. The archive is decrypted in memory and never written to persistent storage. The password is used for the decryption and nothing else: it is not stored, not logged, and not retained after the response is sent. Neither is the file. There is no account and nothing to delete afterwards, because nothing was kept - the why PrivConvert page explains how that is enforced.

That said, the durable advice is the same as for any password: if an archive's password protected something genuinely sensitive and it has now passed through several hands, rotate it. That is true regardless of which tool you used.