On Sep 17, 8:24 pm, Bill Janssen <jans...@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).
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