Nick> I think one of the special things about Python is its batteries
Nick> included approach, and a crypto library would seem to be an
Nick> obvious battery to install since it doesn't (or needn't) depend on
Nick> any other library or application.
Obvious for some I suppose (I've never used any). While it might be
convenient to not have to distribute some third party library in addition to
Python, there is a fundamental problem implementing a crypto algorithm from
scratch for inclusion into Python. There is always the problem that the new
code has to be more rigorously tested than typical code and new bugs means a
new distribution of Python, not just a replacement library. A bug in code
that is not security-related generally means something doesn't work and only
rarely means a security hole has been opened on the computer. A bug in
security-related code more often means the latter as well. I'd much rather
trust a widely-disseminated piece of crypto code that is simply wrapped by
Python than one that was written expressly written for Python (and that will
likely not be exercised much outside the Python community).
I realize the sha module is incorporated this way. It has this comment:
* This code for the SHA algorithm was noted as public domain. The original
* headers are pasted below.
*
* Several changes have been made to make it more compatible with the
* Python environment and desired interface.
While I imagine the changes were fairly small, the guys involved are all
very smart, and the code is fairly straightforward (little, if any, memory
allocation going on), there is still the possibility that a bug lurks in
either the incorporated code or in the changes to it. How quickly could the
Python community respond if a bug was found and fixed in the public domain
SHA code? How much harder would it be for people to adapt if they had to
reinstall Python instead of just an external library?
Skip
--
http://mail.python.org/mailman/listinfo/python-list
