[Python-ideas] adding digital signature and encryption "hashes" to hashlib?
Bill Janssen
janssen at parc.com
Tue Sep 22 19:00:04 CEST 2009
CTO <debatem1 at 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.
> > 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.
Bill
More information about the Python-ideas
mailing list