2
$\begingroup$

I'm adding password protection/encryption support to a Python package that makes ZIP files (https://github.com/uktrade/stream-zip). I'm opting to not add ZipCrypto support, but instead add WinZip-style AES

From https://www.winzip.com/en/support/aes-encryption/ WinZip has two versions of this, AE-1 and AE-2, and it looks like WinZip changes the version used depending on the size of the file.

As of WinZip 11, WinZip instead uses AE-1 for most files, storing the CRC as an additional integrity check against hardware or software errors occurring during the actual compression/encryption or decryption/decompression processes. WinZip 11 will continue to use AE-2, with no CRC, for very small files of less than 20 bytes.

I need to decide what the Python package does in terms of using AE-1 and AE-2. So far, I've made it create ZIP files that use AE-2 for everything. That is, not including the CRC in the ZIP file.

But in terms of next steps:

a) Should I make it use AE-1 for larger files like the WinZip specification suggests

b) Or should I continue to use AE-2 for everything

or c) Something else?

And if a), then is the 20 byte minimum limit for AE-1 of the compressed data or uncompressed data? The encryption happens after compression, so there is a choice here as well (albeit it's maybe slightly awkward to code up if it's 20 bytes after compression due to the streaming nature of stream-zip - avoiding loading all plain/cipher text in memory at once)


Originally posted at https://security.stackexchange.com/questions/273936/winzip-ae-2-for-small-files-and-ae-1-for-larger-how-small-how-large-for-each but it was closed

$\endgroup$

1 Answer 1

3
$\begingroup$

From a cryptographic standpoint, AE-1 is broken: it leaks the CRC of the plaintext, which allows to verify a guess of the plaintext with good certainty (e.g. together with the size, this can be enough to confirm that a file is a certain video). This is acknowledged in the linked "AES Encryption Information" page:

Because for some very small files the CRC can be used to determine the exact contents of a file, regardless of the encryption method used, WinZip 11 continues to use the AE-2 file format, with no CRC stored, for files with an uncompressed size of less than 20 bytes. WinZip 11 also uses the AE-2 file format for files compressed in BZIP2 format, because the BZIP2 format contains its own integrity checks equivalent to those provided by the Zip format's CRC.

Thus if you must use WinZip-style AES in a general-purpose library, that should be AE-2 only (option b).

In an ideal world, you would not use WinZip-style AES at all! It has multiple problems:

  • It uses PBKDF2-HMAC-SHA-1 to turn password into key. This is the key derivation function that dictionary-based password crackers hope you are using: their GPUs, FPGAs, or ASICs are orders of magnitudes faster than software implementations used by legitimate users, which are proportionally less safe.
  • Worse, based on the linked "AES Encryption Information" page, the iteration count for PBKDF2 is fixed to 1,000, which is ridiculously little (it was already too little in 2000, and today we'd need 1,000,000,000 to get an equivalent protection). There seems to be no way to change this while remaining compatible with WinZip.
  • There are other holes: e.g. it's possible to alter an archive with multiple encrypted documents, replacing all encrypted documents except one with unencrypted documents, so that the right password will be required at decryption time, but the decrypted documents (except one) are what the adversary wants rather than the originals. I don't know which WinZip and compatibles (if any) issue a warning in this case, but some did not.

Thus my recommendation is (option c): stay away from WinZip-style AES, which specification is broken and irreparable. If you must use it, use AE-2, and make your best to enforce a large random password (for a start, call it passphrase; and make it the default that it is generated by you, not the user).

$\endgroup$
2
  • $\begingroup$ Thanks for this - extremely helpful. One thing I am wondering though, WinZip 11 uses AE-1 for most files (bigger than 20 bytes?), while 9 and 10 used AE-2 for all files. This seems like a step backwards... Why would they do this? Is the integrity check really worth it? $\endgroup$ Jan 4 at 19:56
  • 2
    $\begingroup$ My guess is WinZip 11 uses AE-1 for large files on the false premise that knowing the CRC of a large file is not useful, because it reveals such a tiny fraction of it's total info. Which is wrong in some circumstances, e.g. proving that an archive contains encrypted versions of known files, which could be the goal of e.g. the police to demonstrate that a file contains encrypted version of prohibited material (like images of war atrocities that leaked to the free press). WinZip designers made so many disputable crypto choices that another one is not surprising. $\endgroup$
    – fgrieu
    Jan 4 at 20:46

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.