# How safe can PKZIP-compatible encryption be?

PKZIP encryption has been around since 1990, and its decryption is directly supported in most desktop environments (Windows, MacOS, most Linux distros). This makes it one of very few options when recipients are not allowed to run any unknown program (as often enforced by an IT department), and the most likely to allow smooth decryption by an unspecified legitimate receiver holding the password.

However, as usually practiced, it has poor security by modern standards: it is very vulnerable to password guess (less than 2-8 of random password guesses remain after a fast test, and only 2-32 of that survives a further test decompressing the shortest file in the archive, or less costly). And even with a high-entropy password it is very vulnerable when an adversary knows the start (sometime even part of) any file bundled in the archive; or when the archive contains many files; or when the archive was prepared with a tool using a poor entropy source, as many are. See this answer for references.

We want to make PKZIP encryption secure by modern standards, while keeping compatibility with the deployed decryption tools. That seems possible with an entropic-enough password, and by allowing that the output of the decryption step is a zip-compliant archive holding the plaintext files, rather then the plaintext files themselves.

How safe can an encryption method be, while allowing decryption with standard PKZIP tools? That should be any one of [PK1993], and modern Unix tools based on Info-ZIP [IZ2008].

We allow:

1. A two-steps decryption, where we first decipher an encrypted zip archive using a password, yielding one intermediary zip archive; and then decompress that, preferably without a password, extracting the original plaintext file(s).
2. A custom encryption tool preparing the intermediary zip (from the payload files, or from a standard zip archive of these) and the final encrypted zip, with access to a secure entropy source.
3. A high-entropy password assumed secretly transmitted by some secure channel. If necessary, we could restrict to a single-use password (e.g. generated by the encryption tool at each use).
4. Restrictions built into the decryption tool used, or in the zip file format, like loosing exact file names or attributes in the decompression step, or size limits.
5. Less than optimal compression (say, typically no worse than 20% + 10kB more than a common zip tool).

We want good practical security under the assumption that all except one portion of one plaintext file is known or chosen.

In other words: How safe can we make the CRC-and-LCG-based cipher of PKZIP, when used with a high-entropy password, and enciphering much-random-like data crafted by the encryption process? Said data, when decrypted then decompressed by the existing decryption tool, is constrained (only) to be a valid zip archive that itself decompresses to the plaintext file(s) using a second invocation of the tool.

The allowances aim at making practically good security achievable:

• The password can have more entropy than the 96-bit internal key, which is respectable and makes pure password or key enumeration practically hopeless.
• 11 out of the 12 bytes of the "encryption header" can be chosen arbitrarily (the last is imposed by zip's quick password check).
• Critically, the intermediary zip file needs not start with the usual PK: without breaking compatibility, we can prepend about to anything without a PK (and more), as long as the fields Offset of local header and Offset of cd wrt to starting disk in the rest are incremented accordingly (per Florian Buchholz's The structure of a PKZip file).
• This freedom, and that build into deflate [RFC1951] (perhaps other supported compression formats), allows removing all except few bits of known plaintext available to an attacker of the CRC-and-LCG-based cipher of PKZIP. That should block the currently published attacks, and make other attacks much more complex.

[PK1993] PKWARE's PKUNZIP.EXE for DOS in zip archive pkz204g.exe (self-extracting on DOS), 1993. SHA-256: 004b48f1cdfe0f31888d213e94ae3997aa5fc02bed8a2d75addaf34ae02d1024.

[IZ2008] Info-ZIP per source in zip30.zip, 2008. SHA-256: 7061ceac0407682b6dc54bb480347205f680f4e56cf34fe1423df2309f18968a.

[RFC1951] DEFLATE Compressed Data Format Specification version 1.3, 1996.

• By ciphertext only attack, I mean an attack where only redundancies in the plaintext are known, but not the actual contents of the plaintext. But even if there are no redundancies, the use of nested Zip files will give enough known plaintext. It might be better to additionally ask a question about whether or not attacks exploiting redundancy in the plaintext are possible for ZipCrypto, since the answer to this question is "not at all [safe]", if only due to the known plaintext in a working PKZIP file (even with a slightly mangled header). Aug 30 '19 at 7:46
• Aug 30 '19 at 7:54
• @Forest: agreed, enough redundancy in the plaintext can allow a practical ciphertext-only attack for a poor cipher (including, stream); and allows key enumeration for almost any cipher. And the reference you cite is spot-on. Notice that it says "there's almost no way to get it right unless you have the beginning of the file.". We can have a random start of file, and that does not break compatibility when you accept the two-step decryption (see 1 in the question, and the butlast bullet).
– fgrieu
Aug 30 '19 at 8:28
• I see. I'll delete my answer since it's not complete enough as is. I would still very, very strongly recommend against using a CRC-based cipher and modifying the plaintext so that it avoids characteristics that are required for known attacks. ZipCrypto isn't just "pretty bad". It's totally, fatally broken. Aug 30 '19 at 8:38
• @forest: The OP's restriction "not allowed to run any unknown program" seems to imply even the inability of running well-known programs such as 7-zip itself. In that case, the restriction would seem to apply even more so to random programs downloaded off the internet, which is what a self-extracting archive essentially is. Aug 30 '19 at 17:32