[Python-ideas] adding digital signature and encryption "hashes" to hashlib?
janssen at parc.com
Tue Sep 22 03:37:33 CEST 2009
Robert Kern <robert.kern at gmail.com> wrote:
> On 2009-09-21 16:37 PM, Bill Janssen wrote:
> > 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.
> Going back to CTO's original reply, I would say that he agrees with
> you. Where he (and I, for that matter) diverge is that we don't think
> they should go into hashlib. The name is inappropriate and
OK, so let's not do that, then. Greg commented that the underlying C
implementation of access to EVP can be shared, which eliminates the only
real functional justification for adding it to hashlib, which is to
avoid duplicating code.
Suppose we added, then, a simple-minded API to the EVP functions:
EVP_Seal... and EVP_Open... provide public key encryption
EVP_Sign... and EVP_Verify... provide digital signatures
EVP_Encrypt and EVP_Decrypt provide symmetric key encryption
(The EVP_Digest... API is already brought out by hashlib.)
Let's call this new module "evp". (Or perhaps there should be a
"crypto" package, with "hashes", "encryption", and "signature"
Let's look at symmetric encryption. You'd want to be able to create a
e = evp.encryptor(key, cipher="AES256", padding=True)
"cipher" defaults to AES256, the constructor raises an exception if that
isn't available (or the specified cipher isn't available), or for a bad
key (wrong length).
e.update(plaintext) # repeat as needed
ciphertext = e.result()
Very similar for decryption.
What can be done to make something like this foolproof?
More information about the Python-ideas