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:
- 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).
- 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.
- 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).
- 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.
- 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 aPK(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.
