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

CTO debatem1 at gmail.com
Sun Sep 20 04:28:42 CEST 2009

On Sep 17, 8:24 pm, Bill Janssen <jans... at parc.com> wrote:
> A couple of weeks ago, there was a discussion on python-dev about adding
> the ability to load modules from encrypted zip files.  I'm not sure the
> discussion went anywhere, and I was on vacation when it took place.
> 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 like the idea of putting more cryptographic power in the
standard library.

> With this, it would be fairly trivial to implement strong encryption of
> zip files (or anything else), and this could then be used to do the
> import feature.
> I'd envision adding new constructors to hashlib:
>    sig = hashlib.signature([data] [, keyfile=...] [, signature_algorithm=...])
> This would have the regular update() method, and digest() and
> hexdigest(), but would also support the method
>    sig.verify(existing_sig)
> which would return a boolean saying the "existing sig" is a verified
> signature for that data.
> Similarly, encryption/decryption would be
>    enc = hashlib.encryptor([plaintext] [, keyfile=...] [, ciphers=...])
> enc.digest() would give the ciphertext.
> And
>    dec = hashlib.decryptor([ciphertext] [, keyfile=...] [, ciphers=...])
> and dec.digest would yield the plaintext.
> The encryptor and decryptor constructors could take either "key" or
> "keyfile" parameters.  Using "key" would support symmetric encrytion,
> while using "keyfile" would produce EVP envelope encryption/decryption.
> Bill

My only real concern about this approach is that it glosses over the
complexity of selecting and using a cryptosystem. How about passing
on having a default for the 'cipher' argument, at least?

Geremy Condra

More information about the Python-ideas mailing list