[ python-Bugs-1123660 ] add SHA256/384/512 to lib

SourceForge.net noreply at sourceforge.net
Thu Feb 17 03:52:06 CET 2005


Bugs item #1123660, was opened at 2005-02-15 23:14
Message generated for change (Comment added) made by tjreedy
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: Terry J. Reedy (tjreedy)
Date: 2005-02-16 21:52

Message:
Logged In: YES 
user_id=593130

Yes, feature request = RFE.  However, this somehow got into 
the tracker as a bug item, not an RFE item.  Check the top of 
the page or beginning of email subject line or body text.  
Hence my comment.

My FYI legal issue summary was based on a PyDev thread 
within the last week and the Contribution pages at 
python.org.  I have no opinion on the lawyer dispute over 
PD.  PSF's lawyer wrote his opinion in a LinuxJournal piece 
referenced in that thread.  PSF Board is inclined to follow 
advice paid for.

Yes, Sha module should be maintained by one person.  Hope 
one of crypto people sees and responds to this item.

There is also a current PyDev thread about sha?, md5, ssl, 
and licensing, but I barely paid attention.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2005-02-16 20: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-16 20: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-16 20: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-16 19: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


More information about the Python-bugs-list mailing list