[Python-Dev] SHA-256 module

[Trevor Perrin]

At 10:15 AM 6/30/2004 +0100, Michael Hudson wrote:
>Trevor Perrin <trevp at trevp.net> writes:
>
> > I think SHA-256 does, since SHA-1 is skimpy for a lot of uses.
>
>Nevertheless, am I right to still believe that there are no known
>distinct strings which even MD5 to the same hash?

Yes, though there's a distributed computing project looking for a 
collision, and they expect to succeed in a couple years.
http://www.md5crk.com/


> > 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.
>
>Unfortunately, distributing crypto software is still a hideous
>international mess (just because the *US* is less silly these
>days...).

Things have been liberalizing rapidly.  I'm not sure how true that is 
anymore, though I don't have direct experience (aside from offering some 
crypto software on a website; people download it from all over the place, 
but maybe they're scofflaws, who knows).

I know US export is no problem.  According to [1], most countries have no 
laws restricting imports, with the notable exception of ex-USSR countries 
and China, which require licenses.  I've heard anecdotally the Russian 
requirements are mostly ignored [2].  I don't know about China.

More anecdotal evidence: The windows python installer includes strong 
crypto (SSL).  Has that caused problems?

Regardless, we could offer a no-crypto distribution.  It would be 
interesting to see how many people download it.  If not many, then it could 
be abandoned....


A.M. Kuchling wrote:
 > One significant reason for the larger SHAs to generate 256-bit keys
 > for AES encryption; it's better to have a larger hash than to take a
 > smaller one and replicate portions of it.  But, given that we're not
 > going to include AES in the Python stdlib, people will have to
 > download a separate library anyway. This library could include SHA256,
 > so this application isn't a compelling reason to add SHA256 to the
 > stdlib.  It would be different if there were existing protocols that
 > need the larger hash, such as HTTP digest auth; are there any?

There's protocols that can use SHA-256, like SSH, S/MIME, or PGP, but these 
all require other crypto primitives, so your point stands.  And I 
agree:  crypto primitives should probably be considered as a lump.  If 
ciphers are absolutely not going to get in, putting in other crypto stuff 
is not that helpful..


Trevor

[1] http://rechten.uvt.nl/koops/cryptolaw/cls-sum.htm
[2] 
http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1997-03/0023.html