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

CTO debatem1 at gmail.com
Tue Sep 22 18:44:07 CEST 2009

On Sep 21, 9:37 pm, Bill Janssen <jans... at parc.com> wrote:
> Robert Kern <robert.k... 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.

Seems reasonable.

> 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.)

Since we're doing the rest of it, we might as well do the
EVP_PKEY stuff too.

> Let's call this new module "evp".

Not a big fan of that, although as long as everything in it
is clearly marked as to what its purpose and limitations are,
I don't really care about the name...

> (Or perhaps there should be a
> "crypto" package, with "hashes", "encryption", and "signature"
> submodules.)

...except that it probably shouldn't conflict with existing
third-party modules, and Crypto is already in use. I'll send
an email and see if there are any plans to change the
capitalization on that.

> 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).

I'm personally against the idea of default ciphers, etc.
Since difference ciphers, keylengths, and padding choices
have immediate consequences for what kinds of security
you're going to have, I would rather be explicit than
implicit here.

>   e.update(plaintext)           # repeat as needed
>   ciphertext = e.result()
> Very similar for decryption.

Most ciphers are not stream ciphers, so it doesn't make a lot of
sense in the case of, say, RSA or AES, but again- bikeshedding.

> What can be done to make something like this foolproof?

Not a whole lot, but, that's kind of the way security works.

Geremy Condra

More information about the Python-ideas mailing list