[Python-Dev] SHA-256 module
trevp at trevp.net
Wed Jun 30 12:33:18 EDT 2004
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.
> > 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
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 , 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 . 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
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..
More information about the Python-Dev