Comment 13 for bug 236170

Our new mutable file design (source:docs/mutable.txt) requires public key cryptography.

The aforementioned (comment:6) thing about someone maintaing pycrypto hasn't panned out -- nobody responded to the patches I submitted.

Oh boy, and now I see that the current version of pycrypto -- v2.0.1 -- has *another* bug which causes SHA-256 to give incorrect results:

http://sourceforge.net/tracker/index.php?func=detail&aid=1740198&group_id=20937&atid=120937

This bug report and accompanying patch has been open since June. This is another demonstration that pycrypto is unmaintained.

This also raises the question: why are we copying our hash function code from pycrypto ? Let's copy hashlib from python 2.5 instead.

Likewise, I'm a bit reluctant to depend on the RSA implementation from pycrypto.

I would be delighted if someone would make a Python wrapper around [http://cryptopp.com Crypto++].

I might try it myself.

Crypto++ has the following features:

 * actively maintained by Wei Dai, who is very smart
 * very portable (see the portability matrix on the front page)
 * high quality code -- the first ever open source sofware to get FIPS 140-2 certification, for example
 * all the algorithms we could ever want, including Tiger hash, elliptic curve signatures, salsa-20, ...
 * extremely high-performance (assembly-implementation) versions of many of the algortihms
 * high-performance (C or C++-implementation) versions of all of the algorithms

It has the following drawback:

 * C++, and not your typical "subset of C++" either, but the real deal with cleverly parameterized templates pouring out of its ears

There are so many ways to make Python wrappers nowadays:

 * hand-rolled
 * pyrex
 * ctypes
 * SWIG