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

[Gregory P. Smith]

On Sun, Sep 20, 2009 at 11:52 AM, CTO <debatem1 at gmail.com> wrote:
>
>
> On Sep 20, 1:07 pm, Bill Janssen <jans... at parc.com> wrote:
>> CTO <debat... at gmail.com> wrote:
>> > > However, it reminded me of an idea from a couple of years ago: extend
>> > > the hashlib module to produce two additional kinds of hashes: a digital
>> > > signature for some sequence of bytes, and an encrypted/decrypted version
>> > > of a sequence of bytes.  Basically, the would bring more of the OpenSSL
>> > > EVP API out to Python (hashlib already uses OpenSSL EVP for various hash
>> > > formations).
>>
>> > >http://www.openssl.org/docs/crypto/evp.html
>>
>> > Besides the fact that hashes and encryption are pretty much totally
>> > different
>>
>> I know it seems that way at first glance, but in fact they are strongly
>> related.  There's a reason all three (and nothing else) are exported
>> through OpenSSL's EVP API.
>>
>> Bill
>
> Don't get me wrong, I like the basic idea you're advancing, and in
> use hashes and crypto are frequently seen together, but they solve
> different problems in *very* different ways. The fact that you-
> who obviously have some interest in crypto and presumably a good
> deal of knowledge about it- seem to be under the impression that
> RSA and SHA have some kinship, well, it doesn't reassure me about
> the ability of non-experts to figure out what's what. IMO, adding
> public key crypto routines to hashlib seems almost guaranteed to
> increase that confusion. Others will doubtless disagree.
>
> Geremy Condra

I don't like the attempt to overload the hash function API.
Encryption and decryption should not be done using a digest() method.
That makes no sense.  They are stream APIs with a constant mapping of
bytes in to bytes out rather than a hash function that always outputs
a constant number of bytes.

I wouldn't put signing functions in hashlib itself but any common EVP
wrapping code under could be shared.  Before doing that I really
suggest someone fleshes out the API and limits its scope to avoid
feature creep.

http://pycrypto.org/ is the API that most Python code wanting crypto
services use today.