1
$\begingroup$

I will need to distribute a file to people for a challenge and I need them to open the file at the same time. The file will be provided a couple of days before the challenge. For maximum compatibility (so no need for 3rd party software, just OS supplied tools) I was thinking of using a password protected Zip 2.0 file.

After some reading I think this will be OK, but I'm not sure. I can't seem to find information on my specific use case (the file only needs to be secret for a short amount of time).

There will be only one file and I will use a 5 word diceware password to make it easy for entering the password while keeping quite a bit of enthropy.

Will this keep my file secure for about a week, assuming people don't have access to big computing clusters?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ For anybody reading this: a 5-word-diceware-passphrase has about 64-bit entropy, meaning it's an interesting question whether a week will suffice for brute force. Further FYI: This corresponds to $2^{44.8}$ password tries per second. $\endgroup$
    – SEJPM
    Commented Apr 8, 2016 at 21:39
  • 2
    $\begingroup$ related: "ZIP 2.0 encryption bruteforce attack" $\endgroup$
    – SEJPM
    Commented Apr 9, 2016 at 10:52

3 Answers 3

Reset to default
1
$\begingroup$

I just stumbled on http://www.tomshardware.com/reviews/password-recovery-gpu,2945-5.html. Although it's a bit old, it does give me some perspective. It mentions ~30 million password tries per second on a Zip 2.0 file. So if someone had a that can perform 10 times as much tries per second, they would need (6^5)^5 / 300 000 000 = ~94767626766 seconds = ~3000 years. I don't think anyone will be spending time and money on a 200000 node cluster to bring this down to ~5 days.

@SEJPM, thanks for your comment that gave further thought to my own question. I was wondering, how did you come up with 2^44.8? If I calculate (6^5)^5 / 7 / 24 / 3600 I get 2^45.4. Is there a something I'm overlooking?

Improve this answer
$\endgroup$
1
  • $\begingroup$ I was using $2^{64}\approx (6^5)^5$ as an approximation and the final difference is negligible. $\endgroup$
    – SEJPM
    Commented Apr 12, 2016 at 20:19
1
$\begingroup$

To my current knowledge, the content of a Zip 2.0 file is likely safe for a week, assuming

  • the password has large entropy (>95 bits; 16 random characters among uppercase, lowercase and digits qualify, and will work with most pkzip-2-crypto-compatible unarchivers); with 64 bits, I would not bet the house against a determined adversary with a large FPGA (or GPU) farm, and a some prior effort on that problem;
  • there is a single file in the archive;
  • very little is known by the adversary about that file; especially, its beginning is pretty much unknown, and no large sub-string of it is known;
  • the archive is made by the relatively well studied PKZIP 2.04g of 1993-02-01 (md5 e5a48751250ffa94a8cf2ecaf8073098), with no unusual option except -s, running on a machine (or Virtual Memory, DOS emulation..) that does not interfere with the operation of its RNG; there exist other zip programs that generate encrypted archives compatible with PKZIP 2.04g, but have a predictable RNG, making them unsafe.

For details and references, see this.

Improve this answer
$\endgroup$
0
$\begingroup$

The PKZIP legacy encryption is a stream cipher with a 96-bit state.

From this answer about the possibility of brute forcing an encrypted archive

Baring hypothesis change or progress in some of the above, it is inconceivable that the original file data can be recovered from the archive using anything remotely comparable to the computing effort that a GPU cluster can make in its operational life: if we had a thousand units of some kind each weeding a hundred thousand keys per microsecond for a century, odds are one in a thousand that the right key would be found.

The answer also refers to several papers published about known plaintext attacks on this cipher. The problem here is that, because the files are compressed, there is little real known plaintext to use.

Improve this answer
$\endgroup$
3
  • 2
    $\begingroup$ Zip compresses and encyrpts files individually, not the whole archive at once. So make sure you don't include a well-known file (for example a copy of the GPL) in your tree. $\endgroup$
    – Peter Green
    Commented Apr 12, 2016 at 1:43
  • 1
    $\begingroup$ You removed "Baring hypothesis change or progress in some of the above" before my statement; among the perhaps unfounded hypothesis are: a single file is encrypted, and nothing is known about its content (it is random, most importantly its beginning), and PKZIP 2.04g was used, and no weakness is discovered about its RNG (or appears, e.g. due to running it in some VM context). All in all, I see a problem with direct use of my statement in the context of this question. $\endgroup$
    – fgrieu ♦
    Commented Apr 12, 2016 at 5:55
  • 1
    $\begingroup$ @fgrieu I quoted you in full. $\endgroup$
    – user9070
    Commented Apr 12, 2016 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.