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
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