Near Final PEP 247 - API for Cryptographic Hash Functions

Aahz Maruch aahz at
Sun Sep 30 19:58:19 CEST 2001

In article <mailman.1001707952.19388.python-list at>,
Andrew Kuchling  <akuchlin at> wrote:
>On Fri, Sep 28, 2001 at 11:14:36AM -0400, aahz at wrote:
>>I would like to see the argument for returning digest_size in bytes when
>>it is actually a bit string.  (Yes, I know the chance of having a
>We program in a byte-oriented world. :) The bit size is rarely a
>useful number, while if you're extracting a digest from a string (
>s[pos:pos+md5.digest_size]) or a file ( you
>care about the byte numbers.  A quick grep through amkCrypto Pisces
>doesn't turn up any code that needs the number of bits, but there are
>lots of uses of the number of bytes.

That is all true, but you deleted my main point, which is that given
that the digest is in fact a bit string, is there any reason to avoid
future-proofing against new algorithms that may not return a
byte-integral number of bits?  This *is* a PEP, after all.  ;-)

Also, algorithms such as MD5 are always specified as 128-bit, not
16-byte, so from a clarity standpoint (if not the most useful), bits
make more sense to me.

>>What exactly does update() do?  Does it replace or append?
>"Append", meaning that the string is hashed into the current state of
>the object.

The documentation should definitely be clarified, and I suggest changing
the name to append().
                      --- Aahz  <*>  (Copyright 2001 by aahz at

Hugs and backrubs -- I break Rule 6       
Androgynous poly kinky vanilla queer het Pythonista   

We must not let the evil of a few trample the freedoms of the many.

More information about the Python-list mailing list