Robert Kern <robert.kern@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" submodules.) 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? Bill