Near Final PEP 247 - API for Cryptographic Hash Functions
aahz at panix.com
Sun Sep 30 19:58:19 CEST 2001
In article <mailman.1001707952.19388.python-list at python.org>,
Andrew Kuchling <akuchlin at mems-exchange.org> wrote:
>On Fri, Sep 28, 2001 at 11:14:36AM -0400, aahz at panix.com 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 (file.read(md5.digest_size)) 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 documentation should definitely be clarified, and I suggest changing
the name to append().
--- Aahz <*> (Copyright 2001 by aahz at pobox.com)
Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
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