[Python-Dev] AES decryption/encryption support for zipfile
Gregory P. Smith
greg at krypto.org
Mon Sep 10 14:56:23 EDT 2018
On Wed, Sep 5, 2018 at 8:24 AM 大野隆弘 <oono0114 at gmail.com> wrote:
> Sorry, allow me to ask one more thing.
> If I want to use AES in zipfile module, what the good way to implement?
If anyone wants to add support for additional zipfile encryption/decryption
methods, there are a few options:
(a) Fork the stdlib zipfile module and create one that supports the
additional features, posting it on PyPI. That way it could have
dependencies on other third party libraries such as
(b) Figure out the set of hooks necessary for the zipfile module to support
pluggable encryption as an API so that external libraries could provide
encryption support to it.
(c) Write a library that wraps an existing third party zip file creation
tool or library instead of reusing the stdlib zipfile code.
Option (a) is probably easiest to start with... but creates a maintenance
burden of keeping that module up to date.
Option (b) will be more challenging, the zipfile API modifications and
their tests would need merging and would only show up in a future CPython
release (3.8 today).
Option (c) is entirely different, but would get you out of the business of
dealing with the zipfile spec itself.
Unstated option (n): write something entirely new not based on existing
code or tools. An entirely different form of challenge.
In general the existing stdlib zipfile module code is not loved by any of
us who have had to work on it in the past decade, it is a hairy mess (but
does work, so it's got that going for it). Granted, the zip format as a
specification vs the many implementations out there to be compatible with
is also what I'd call an underspecified mess...
> Thanks and Regards,
> Takahiro Ono
> 2018年9月5日(水) 23:01 大野隆弘 <oono0114 at gmail.com>:
>> Christian, really appreciated the details. I understood.
>> Is wrapper library like ssl module with openssl on platform also not good
>> My intention is not re-invention but single standard way as standard
>> If I can read past discussion somewhere, it's also appreciated
>> Thanks and Regards,
>> Takahiro Ono
>> 2018年9月5日(水) 1:48 Christian Heimes <christian at python.org>:
>>> On 2018-09-04 16:37, 大野隆弘 wrote:
>>> > Dear all,
>>> > Have we tried cipher implementation includes AES as a standard library
>>> > in the past?
>>> > https://docs.python.org/3.6/library/crypto.html
>>> > if possible I want to try to implement AES because famous 3rd party
>>> > library is not maintained and general cipher programs should be used
>>> > multiple purpose.Though the implementation is tough, I believe this
>>> > should be worth to it.
>>> > In my case, I want to use AES implementation for zipfile module.
>>> strong -1
>>> The Python standard library doesn't contain any encryption, signing, and
>>> other cryptographic algorithms for multiple reasons. The only exception
>>> from the rule are hashing algorithms and HMAC construct. There are legal
>>> implications like export restrictions. Crypto is just too hard to get
>>> right and we don't want to give the user additional rope. We already had
>>> a very lengthy and exhausting discussion for the secrets module. That
>>> module just provides a user-friendly interface to CPRNG.
>>> By the way, AES by itself is a useless to borderline dangerous
>>> algorithm. It must be embedded within additional layers like block mode,
>>> authenticated encryption / MAC, and more. There isn't a single correct
>>> answer for block mode and AD algorithm, too. It highly depends on the
>>> problem space. While GCM AEAD mode is good choice for network
>>> communication, it can be a pretty bad idea for persistent storage.
>>> There is one excellent Python library with high level and low level
>>> cryptographic algorithms: http://cryptography.readthedocs.io/ . It's t
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev