[PYTHON-CRYPTO] Reviving PEP 247: Hashing API
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