From the official ZIP files specification: This form of encryption is considered weak by today's standards and its use is recommended only for situations with low security needs or for compatibility with older .ZIP applications. I think that the support of encrypting ZIP files using the traditional PKWARE encryption was intentionally omitted in the zipfile module, because we don't want to encourage using such weak encryption method. If you need to add encrypted data in the ZIP file, use third-party tools for encrypting it before adding to the ZIP file or encrypting the whole ZIP file after creating. I'm -1 for adding support of weak encrypting. Of course, adding support for the strong (AES) encryption in ZIP files would be nice. But this task is much more difficult.
Agree, we should not enhance weak encryption to the world. But unfortunately, MS Windows supports only this type of encryption as far as I researched. https://blogs.msdn.microsoft.com/oldnewthing/20180515-00/?p=98755 That is the my first motivation of Traditional PKWARE encryption(a.k.a ZipCrypto/Standard Zip 2.0 encryption) support. If this big platform supports AES, we don't have any reason to support. But unfortunately not. On the other hand, encryption algorithm compromising happens forever. I believe python developers must have ability to make decision of suitable algorithm because "We are all (consenting) adults here".(I love this phrase) Also implementing other algo (including AES) support must affect to decryption of zipfile module. As we can imagine it should be big task and should be divided. These are the background of my suggestion. In summary, 1. We don't have to support "weak" encryption like DES/RC2 although they are on the document. 2. But Traditional PKWare Encryption is special enough to support because of the circumstances. 3. Other algo support in both decrypt/encrypt should be implemented sooner or later. Any feedback is welcome. FYI : All candidate of Zip encryption --------- (Traditional PKWARE encryption) + 0x6601 - DES 0x6602 - RC2 (version needed to extract < 5.2) 0x6603 - 3DES 168 0x6609 - 3DES 112 0x660E - AES 128 0x660F - AES 192 0x6610 - AES 256 0x6702 - RC2 (version needed to extract >= 5.2) 0x6720 - Blowfish 0x6721 - Twofish 0x6801 - RC4 https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT 7.2.3.2 AlgId --------- FYI 2. Other languages/tools support Perl : "Support Encryption" is in TODO https://metacpan.org/pod/Archive::Zip Go : Both (AES/Traditional) encryption is going to be integrated( discussion was suspended?) https://github.com/golang/go/issues/12081 Ruby : Supports as experimental https://github.com/rubyzip/rubyzip/blob/master/README.md WinZip : Supports but not recommended. http://kb.winzip.com/help/help_encryption.htm
What is the reason of using such weak encryption? It looks to me that creating a non-encrypted ZIP file and encrypting it with third-party tools is the right way if you need an encryption.
