How long should zip encryption password be for it take 10 years to crack?

Question

I am using zip 3.0.0 on macOS High Sierra and Ubuntu. Here is my zip version on macOS:

$ zip --version | head
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon.  Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.

Compiled with gcc 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14) for Unix (Mac OS X) on Feb 22 2019.

Here's the one on Ubuntu:

$ zip --version | head
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon.  Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.

Compiled with gcc 6.3.0 20170221 for Unix (Linux ELF).

I have read this answer at https://security.stackexchange.com/a/186132/108239 which recommends against using zip for encryption.

However, in the environment I am in, I need to send a file securely to non-technical users. Here are my constraints:

• I am allowed to send my recipients an arbitrarily long password.
• I am allowed to send them zip files (encrypted or unencrypted).
• I am not allowed to ask my recipients to install additional software.
• I only care about confidentiality of the content of the file.
• I do not care about the confidentiality of the filename or file metadata.
• I do not care about integrity or non-repudiation.

Given these constraints, so far I have been sending files this way:

zip -e secret.zip secret.txt

I use a 80-character long randomly generated alphanumeric (A-Za-z0-9) password to encrypt the secret file. The zip utility does not accept passwords any longer. Trying to do so results in the (line too long--try again) error.

This uses the following crypto method:

$ 7z l -slt secret.zip | grep Method
Method = ZipCrypto Deflate

My questions:

• Is a 80-character long randomly generated alphanumeric password strong enough to compensate for the weak cipher technology of zip utility?
• What is the minimum entropy that a password should have to make it secure enough to be used with the zip utility? To define "secure enough", say, cracking the zip file should take 10 or so years with the current computing power (ignore an increase in computing power for now for the sake of simplicity).

Answer 1

If you are using ZipCrypto for encryption, then any password length is insecure.

You are using the ZipCrypto cipher, rather than the more secure AES. ZipCrypto is extremely weak, as it is based internally on a non-cryptographic construction called a CRC. It is highly vulnerable to a known-plaintext attack, which in practice does not require knowing exactly what your Zip file contains, only a minuscule portion. This can typically be satisfied by using the header of a file, which is typically known for the vast majority of commonly compressed files.

The attack, discovered in the 90s, is detailed in A Known Plaintext Attack on the PKZIP Stream Cipher. With 13 bytes of known plaintext, the full key can be recovered with a complexity of 2³⁸, which is not much. In fact, it took only a few hours on a personal computer, and that was with 90s hardware! Attacks only get better over time, and the attack against ZipCrypto is no exception to this trend: An Improved Known Plaintext Attack on PKZIP Encryption Algorithm.

---

If you switch to the newer Zip encryption format which supports AES, then you can securely encrypt files and trust that they will stay confidential indefinitely. Assuming you want a minimum of 128 bits of security and are choosing a password from a set of 62 symbols (an alphanumeric password), you would want to use at least 22 characters, as log₂(62²²) ≈ 131 bits and, obviously, 131 ≥ 128. Zip encryption of any kind does not provide integrity, but you specified that you only need confidentiality.

Answer 2

This is two questions in one. One is easy, one is hard. Let's start with the easy one:

How long should my encryption password be for it to remain safe for 10 years?

It is well known that a random 128-bit secret is plenty of entropy to not be cracked, even if it is protected by the fastest possible (but not vulnerable) hashing algorithm. The reason I bring hashing up is because there is a lot of research into, good software for, and a lot of benchmarks for password hash cracking. Decrypting a zip file is basically doing the decrypt operation and checking if you can decrypt a byte of which you know what the value should be. (See section 6.1 of the zip format specification, or the Python implementation.) The only speed indication regarding the cracking of zip files on a GPU is a marketing claim of 10 billion attempts per second. This is mention in some small, grey text with no reference or any more information about their setup. It's a data point to consider, but not a very reliable one. Hashing is similar to this in that hashing algorithms are designed to be very fast, and you also apply some operation and check the result.

For example, MD5 crackers can reach hundreds of billions of attempts per second on moderately expensive hardware. Let's use this as our basis rather than the 10 billion marketing claim, since we don't know what year that was or what setup they used.

Even if we assume that Moore's law holds (it doesn't) and can be interpreted as "computer speed doubles every 18 months" (it can't), then in 10 years, we would have had 6.7 doublings. For convenience's sake, let's say we run at that speed the whole time, so we run at a few hundred billion times 2^6.7, so a few trillion attempts per second (let's say 50 trillion). In 10 years, there are 3600*24*365.25*10 = 316 million seconds. That's 50e12 * 316e6 = 16 sextillion (16e21) guesses... so we will have checked about 73 bits of entropy, or 0.000000000000005% of the possible keys (because log(16e21)/log(2) is ~73 and 16e21/2¹²⁸*100 is the aforementioned percentage).

If you want to play it risky, you could go for a password containing about 80 bits of entropy, and an attacker would have a small (but non-negligible) chance of cracking it. More realistically, you would want to have some margin of error, also in case the encryption algorithm is weakened. I would advise to stick with 128 bits of entropy as a good idea. This also matches what a research project by the European Union concludes: "For general long-term protection (30 years), 128 bit keys are recommended (level 7)." (Source: me on Wikipedia)

If we use a-z, A-Z, 0-9, then each position of your password can have 26+26+10 = 62 possible values. To compute how many characters we need for 128 bits, we can use: log(10^^128*log(2))/log(62) = 21.5 characters (because log(62^21.5)/log(2) = 128).

Answer: 22 randomly generated characters, consisting of the characters A through Z, a through z, and 0 through 9. Example: M89bqltyuPQ0g34Uv2CR6b. No need for an 80-character password like you suggested!

Now the difficult question:

Will zip encryption be safe for 10 years?

There are different kinds of encryption supported by the zip format. I wrote this section under the assumption that zip software uses AES by default these days, not the ancient and broken CRC-based crypto, which forest points out it actually does use by default.

So if you configure the software to use AES:

This is an assumption, but it seems to have withstood quite some time and scrutiny by now. Although there are some attacks known, it appears unlikely that it will be weakened very significantly in the next decade. A quantum computer changes things somewhat, but nobody can say what the timeline for that will be. A decent quantum computer in the next decade, especially available to those who do not have billions of euros to invest in one, sounds very optimistic.

If you are worried about quantum computers, use software that only uses symmetric encryption algorithms and hashing algorithms of at least 256 bits (so your key should contain that much entropy, and the software must use it), such as AES-256 and SHA-256. Depending on which implementation you use, zip might qualify: according to the specification, format version 5.1 adds support for AES-256. The original encryption is symmetric encryption and will not break as catastrophically as asymmetric encryption would, but it uses too short keys. While a quantum computer will weaken symmetric encryption and hashing algorithms, Grover's algorithm tells us that it is basically in the order of halving the number of bits, so a password containing 256 bits of entropy today will, for a quantum computer, be as strong as a password containing 128 bits of entropy.

(Note that you should also apply good password management: don't reuse the password elsewhere or other things that people commonly do wrong with passwords. But how to manage your passwords is out of scope for this answer.)

Answer: If you use zip with AES, then probably yes, but it is impossible to say for sure.

Answer 3

Is a 80-character long randomly generated alphanumeric password strong enough to compensate for the weak cipher technology of zip utility?

Firstly you should be encrypting with a minimum of AES 128, given the 10 years you may want to consider 256 (I’m going leave out quantum possibilities for a decade).

I’m not aware of your zip package, sorry, but if it can’t support that as it’s too old. You might want to check for a newer package as older apps are likely to contain vulnerabilities which leaves you open to being exploited at some point.

Choosen a long and pseudorandom key is yes important. Go as long and random as you can. The safe storage of your key is just as important over 10 years.

What is the minimum entropy that a password should have to make it secure enough to be used with the zip utility? To define "secure enough", say, the zip file should remain uncracked for 10 or so years.

Difficult to say as 10 years could uncover assorts of extra computing power and vulnerabilities within the encryption algorithms. Go long again, and use well trusted pseudorandom generators.