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

Bill Janssen 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
> misleading.

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
new encryptor:

  import evp
  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 mailing list