[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