At 12:04 PM 6/29/2004 -0700, Gregory P. Smith wrote:
>[...]
>The only official SHAs defined are sha1, sha256, sha384 and sha512
Plus SHA-224, which is just SHA-256 with a different initial value and
truncated output (similarly, SHA-384 is just SHA-512 with a different
initial value and truncated output).
(Why so many SHAs? Due to birthday attacks, sometimes hash algorithms have
half the bit-security of their output length, and you might want your
hash's security level to match your cipher's security level. AES has a
security level (i.e. key length) of 128, 192, or 256 bits. 3DES has a
level of 112 bits. SHA-1 was designed as part of a suite including the
Skipjack 80-bit cipher).
> and
>are typically referred to as a single unit name of "sha1" or "sha512"
>not "the SHA which is 512 bits." using a simple function name that is
>the common spoken name is nicer.
Agreed, since SHA-1, SHA-256, and SHA-512 are different algorithms that are
just named similarly.
That's less true of SHA-224 and SHA-384, which *are* just parameterizations
of the other algorithms, and could be done like:
sha256.new('string', bits=224)
sha512.new('string', bits=384)
>Perl uses a top level module to contain all its hash functions
>(Digest::MD5, Digest::SHA1, etc). I agree that we should do that same
>(as someone else already suggested).
Yeah, that also gives room to grow if other hashes become prevalent.
>Realistically, lets not reinvent the wheel. See the pycrypto module:
>
> http://www.amk.ca/python/code/crypto.html
>
>MD5 and SHA1 are the most common types of hashes in use today; those
>make sense to have in the base python distro. Does sha256 or greater?
I think SHA-256 does, since SHA-1 is skimpy for a lot of uses. They're
aren't many SHA-256-using protocols due to inertia, but I think it's
happening. The others I don't see any rush for.
>If someone needs something better than sha1 there is a good chance
>that they are also dealing with symmetric encryption or public key
>authentication and would need a module like pycrypto anyways.
Good point. Probably this and other crypto patches need to viewed in light
of a broader "crypto strategy", whatever that may be.
My thought is that since almost all crypto protocols depend on a tiny
number of primitives (a few ciphers, a few hashes, modular exponentiation,
random numbers), it would be good to have these in stdlib. Otherwise
crypto-using apps require extensions (like pycrypto + GMP) which makes them
hard to distribute.
It would be great to borrow code from pycrypto where possible (for example,
pycrypto has excellent ciphers, though it doesn't have SHA-256). But these
things would be handiest if they came with the standard library.
Anyways, I advocated this below.. I'd be happy to write this up as a PEP
or something, if that would be easier to consider than a scattershot set of
patches?
http://mail.python.org/pipermail/python-dev/2004-May/044673.html
Trevor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4