Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470
Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-02-17 01:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
