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