<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Sep 5, 2018 at 8:24 AM 大野隆弘 <<a href="mailto:oono0114@gmail.com">oono0114@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, allow me to ask one more thing.<div>If I want to use AES in zipfile module, what the good way to implement?</div></div></blockquote><div><br></div><div>If anyone wants to add support for additional zipfile encryption/decryption methods, there are a few options:</div><div><br></div><div>(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 <a href="https://cryptography.io/en/latest/">https://cryptography.io/en/latest/</a>.</div><div><br></div><div>(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.</div><div><br></div><div>(c) Write a library that wraps an existing third party zip file creation tool or library instead of reusing the stdlib zipfile code.</div><div><br></div><div>Option (a) is probably easiest to start with... but creates a maintenance burden of keeping that module up to date.</div><div><br></div><div>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).</div><div><br></div><div>Option (c) is entirely different, but would get you out of the business of dealing with the zipfile spec itself.</div><div><br></div><div>Unstated option (n): write something entirely new not based on existing code or tools. An entirely different form of challenge.</div><div><br></div><div>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...</div><div><br></div><div>-gps</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks and Regards,</div><div>-----------------</div><div>Takahiro Ono</div></div><br><div class="gmail_quote"><div dir="ltr">2018年9月5日(水) 23:01 大野隆弘 <<a href="mailto:oono0114@gmail.com" target="_blank">oono0114@gmail.com</a>>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Christian,
really appreciated the details. I understood.<div><br><div>Is wrapper library like ssl module with openssl on platform also not good idea?</div><div>My intention is not re-invention but single standard way as standard library.</div><div><br><div>If I can read past discussion somewhere, it's also appreciated</div><div><br></div><div>Thanks and Regards,</div><div>Takahiro Ono</div><div><br></div><div><br><div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">2018年9月5日(水) 1:48 Christian Heimes <<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-09-04 16:37, 大野隆弘 wrote:<br>
> Dear all,<br>
> <br>
> Have we tried cipher implementation includes AES as a standard library<br>
> in the past?<br>
> <a href="https://docs.python.org/3.6/library/crypto.html" rel="noreferrer" target="_blank">https://docs.python.org/3.6/library/crypto.html</a><br>
> <br>
> if possible I want to try to implement AES because famous 3rd party<br>
> library is not maintained and general cipher programs should be used for<br>
> multiple purpose.Though the implementation is tough, I believe this<br>
> should be worth to it.<br>
> In my case, I want to use AES implementation for zipfile module.<br>
<br>
strong -1<br>
<br>
The Python standard library doesn't contain any encryption, signing, and<br>
other cryptographic algorithms for multiple reasons. The only exception<br>
from the rule are hashing algorithms and HMAC construct. There are legal<br>
implications like export restrictions. Crypto is just too hard to get<br>
right and we don't want to give the user additional rope. We already had<br>
a very lengthy and exhausting discussion for the secrets module. That<br>
module just provides a user-friendly interface to CPRNG.<br>
<br>
By the way, AES by itself is a useless to borderline dangerous<br>
algorithm. It must be embedded within additional layers like block mode,<br>
authenticated encryption / MAC, and more. There isn't a single correct<br>
answer for block mode and AD algorithm, too. It highly depends on the<br>
problem space. While GCM AEAD mode is good choice for network<br>
communication, it can be a pretty bad idea for persistent storage.<br>
<br>
There is one excellent Python library with high level and low level<br>
cryptographic algorithms: <a href="http://cryptography.readthedocs.io/" rel="noreferrer" target="_blank">http://cryptography.readthedocs.io/</a> . It's t<br>
<br>
Regards,<br>
Christian<br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/greg%40krypto.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br>
</blockquote></div></div>