[Python-ideas] adding digital signature and encryption "hashes" to hashlib?

Paul Moore p.f.moore at gmail.com
Fri Sep 25 14:31:28 CEST 2009

2009/9/25 Antoine Pitrou <solipsis at pitrou.net>:
> Bill Janssen <janssen at ...> writes:
>> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
>> else; I was suggesting that providing easy-to-use APIs to a couple of
>> commonly-requested crypto features, for use by non-cryptographers,
>> wouldn't be a bad idea.
> I think it would be good indeed. Since we already wrapping OpenSSL, let's give
> access to more of its features instead of having people find additional binary
> packages (of varying quality) for their platform.


> As for some of the points which have been raised here:
> - Putting non-hash functions in "hashlib" would look strange.
> - Please don't call the package "evp", it's cryptic (;-)) and tied to a specific
> implementation. "crypto" would be fine and obvious.
> - I don't think there should be a default argument. People shouldn't try to do
> any crypto at all if they aren't able to choose an algorithm. Documenting
> (perhaps recommending) a couple of them (AES, RSA) would be more helpful than
> supporting a silent default.
> - The API needn't (and shouldn't) be the same as for hashing objects. A digest()
> method doesn't make sense. Ideally some of the {en,de}crypting objects could be
> file-like objects, but it's not really necessary IMO (and it can always be done
> in pure Python on top of a lower-level C extension, assuming the extension does
> provide a streaming interface).

Again, +1.


More information about the Python-ideas mailing list