Add encryption support to zipfile

[137e4d2b-609d-4308-ae9e-a8d6654d3e8a]

BPO	34546
Nosy	@Yhg1s, @tiran, @serhiy-storchaka, @mitsuo0114
PRs	python/cpython#9060

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['type-feature', 'library'] title = 'Add encryption support to zipfile' updated_at = user = 'https://github.com/mitsuo0114' ``` bugs.python.org fields: ```python activity = actor = '\xe5\xa4\xa7\xe9\x87\x8e\xe9\x9a\x86\xe5\xbc\x98' assignee = 'none' closed = True closed_date = closer = 'serhiy.storchaka' components = ['Library (Lib)'] creation = creator = '\xe5\xa4\xa7\xe9\x87\x8e\xe9\x9a\x86\xe5\xbc\x98' dependencies = [] files = [] hgrepos = [] issue_num = 34546 keywords = ['patch'] message_count = 6.0 messages = ['324372', '324452', '324454', '324781', '324787', '324845'] nosy_count = 5.0 nosy_names = ['twouters', 'alanmcintyre', 'christian.heimes', 'serhiy.storchaka', '\xe5\xa4\xa7\xe9\x87\x8e\xe9\x9a\x86\xe5\xbc\x98'] pr_nums = ['9060'] priority = 'normal' resolution = 'rejected' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue34546' versions = [] ```

[137e4d2b-609d-4308-ae9e-a8d6654d3e8a]

from https://mail.python.org/pipermail/python-ideas/2018-August/053081.html

I would like to use zipfile encryption as python standard library. https://github.com/python/cpython/blob/master/Lib/zipfile.py

Below document says "currently" cannot. https://github.com/python/cpython/blob/master/Doc/library/zipfile.rst "but it currently cannot create an encrypted file."

Current pythonians like me have to use 3rd party like below, but I believe it is worth to include. https://pypi.org/project/pyminizip/ https://github.com/wllm-rbnt/py-zipcrypt

[serhiy-storchaka]

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.

[137e4d2b-609d-4308-ae9e-a8d6654d3e8a]

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

[serhiy-storchaka]

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.

[tiran]

-1 from me, too.

Serhiy already made a valid point and suggested a better alternative.

[137e4d2b-609d-4308-ae9e-a8d6654d3e8a]

My original reason of this is supporting Windows Explore decryption. That doesn't support AES but support only this traditional PKWARE encryption. In my work, some recipients who received the zip file cannot install 3rd party tools on their Windows https://blogs.msdn.microsoft.com/oldnewthing/20180515-00/?p=98755

But as Christian explained for me in below thread, I understand we should use 3rd party module for this purpose https://mail.python.org/pipermail/python-dev/2018-September/155091.html

Thanks and Regards, ----------- Takahiro Ono

2018年9月8日(土) 6:34 Serhiy Storchaka \report@bugs.python.org\:

Change by Serhiy Storchaka \storchaka+cpython@gmail.com\:

---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed

---

Python tracker \report@bugs.python.org\ \https://bugs.python.org/issue34546\

---