
On Sep 22, 1:00 pm, Bill Janssen <jans...@parc.com> wrote:
CTO <debat...@gmail.com> wrote:
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.
Sure, your privilege.
Unfortunately, most users won't be able to make those choices sanely, and will rely on some sort of external advice about it. So I think it makes sense to try to build some such advice into the code, by adding a reasonably strong encryption standard as a default, and by adding some code to do sanity/compatibility checks on the user-selected keys, if possible.
If you don't know what the application is, you don't know what's secure and what isn't. We have no way of knowing, and so should resist the temptation to guess. It's also worth pointing out that hashlib as currently implemented makes users do exactly this: you have to specify the hash you want, with no default provided. I've never heard anybody describe that as an onerous level of difficulty.
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.
Still, good point. Multiple calls to update() should raise an exception if the chosen cipher is not a stream cipher. Or, allow multiple calls, and buffer the input until result() is called.
AFAIK, AES and RSA are the most commonly used algorithms in EVP. Maybe it would make more sense to take the more traditional keygen-encrypt-decrypt approach? Geremy Condra