[PYTHON-CRYPTO] Reviving PEP 247: Hashing API

Andrew Kuchling akuchlin at mems-exchange.org
Mon Sep 17 19:45:14 CEST 2001

After starting some discussion this spring about a standard hashing
API for Python, I kind of forgot about the issue for a long time.

As an effort at reviving it, I've updated the PEP, and the current
version is at http://python.sourceforge.net/peps/pep-0247.html.

Changes: renamed clear() to reset() (Rich Salz); added hexdigest()
method (Barry Warsaw); added digestsize attribute to objects (Andrew

There's one XXX issue left; what the reset() method does with a hash
that requires keys or other arguments.  The current text is:

        Reset this hashing object to its initial state, as if the
        object was created from new(key=<initially specified key>)
        (XXX what should this do for a keyed hash?  A proposed
        semantic follows:).  There is no way to supply a starting
        string as there is for the new() function, and there's no way
        to change the key specified for a keyed hash.

On further thought, the proposed semantic is bad, because it means
that objects will need to keep a copy of the key around.  I propose
that either 1) reset() raises an exception for hashes with parameters
-- changing the key or number of rounds would *always* require
creating a new object.  Or, 2) reset() takes the exact same arguments
as the constructor, and therefore the object can always be re-created
with any of its parameters being different.

1) is easier to implement, but 2) shouldn't be very hard.  The
constructor would probably initialize the C struct representing an
object, and then call reset() under the covers to do the argument
processing.  So, do people prefer 1 or 2?


More information about the python-crypto mailing list