On Sun, Sep 20, 2009 at 11:52 AM, CTO <debatem1@gmail.com> wrote:
On Sep 20, 1:07 pm, Bill Janssen <jans...@parc.com> wrote:
CTO <debat...@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).
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.