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