[Python-Dev] SHA-256 module

[Trevor Perrin]

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