add SHA256/384/512 to lib

[phr]

BPO	1123660
Nosy	@birkenfeld, @rhettinger, @terryjreedy

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2005-08-25.07:39:08.000>
created_at = <Date 2005-02-16.04:14:34.000>
labels = ['type-feature', 'library']
title = 'add SHA256/384/512 to lib'
updated_at = <Date 2005-08-25.07:39:08.000>
user = 'https://bugs.python.org/phr'

bugs.python.org fields:

activity = <Date 2005-08-25.07:39:08.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2005-02-16.04:14:34.000>
creator = 'phr'
dependencies = []
files = []
hgrepos = []
issue_num = 1123660
keywords = []
message_count = 13.0
messages = ['54379', '54380', '54381', '54382', '54383', '54384', '54385', '54386', '54387', '54388', '54389', '54390', '54391']
nosy_count = 4.0
nosy_names = ['georg.brandl', 'rhettinger', 'terry.reedy', 'phr']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1123660'
versions = []

[phr]

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.

[terryjreedy]

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.

[phr]

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.

[phr]

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.

[phr]

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.

[terryjreedy]

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.

[phr]

Logged In: YES
user_id=72053

I couldn't find the "Contributions" section of Python.org;
got a url?

I did find PEP-241 says public domain is a legitimate choice
of license, and also the PSF patch submission agreement near
the bottom of
http://www.python.org/psf/psf-contributor-agreement.html
suggests releasing the patch to the PD (but only if the
contributor wrote the entire patch, which wouldn't apply to
wrapping some existing public domain work). Also a lot of
the PEP's are released as PD. So maybe you want to revisit
all those docs, if there's now some problem with PD releases.

I think the Linuxjournal article you refer to might be
http://www.linuxjournal.com/article/6225 . It is just
bizarre. Is that the same lawyer? It says he also advises
the OSI, so I might email him with that Bernstein cite.

This tracker item clearly says "Feature request" in the
"Group" pulldown when I look at it in Sourceforge. That's
the way I entered it and if it's showing up differently for
you, something is going wrong somewhere.

[terryjreedy]

Logged In: YES
user_id=593130

Here is the top of this page:
Project: Bugs: Trackers
and here is the beginning of the email sent to me:
Bugs item bpo-1123660, was opened at 2005-02-16 04:14

I found the explanation: on
https://sourceforge.net/tracker/?group_id=5470
you need to click RFE instead of Bugs on this line:
Summary | Admin | Home Page | Tracker | Bugs |
Patches | RFE |

When you click Bugs, Feature Request shows up under
Group because it was put there before there was a separate
RFE list and now, I remember, it cannot be removed.
(SF 'feature') But it would be if it could be.
---

Yes, that is the lawyer and article. Yes, I noticed the
discrepancy 'PD not real' and current PEP PD policy, but
refrained from saying anything yet. I have no more to do
with those and other docs than you do.

Contributor agreements: your link is to a 3 1/2 year old
draft, badly misleading, but first hit on 'contributor' search.
I have suggested its removal. Current, I believe, is
http://www.python.org/psf/contrib which links to
http://www.python.org/moin/PythonSoftwareFoundationLicen
seFaq and
http://www.python.org/psf/contrib-form.html

[terryjreedy]

Logged In: YES
user_id=593130

Addition to the previous: current does not necessarily mean
final. I am not a party to any ongoing non-public discussion
of these issues. Over and out.

[phr]

Logged In: YES
user_id=72053

Well, I don't see an obvious way to reclassify this item.
If someone knows how to do it, please go ahead.

I sent an email to the lawyer and haven't gotten a response
yet.

[terryjreedy]

Logged In: YES
user_id=593130

Ok, next time....
You might want to look at
https://sourceforge.net/tracker/index.php?
func=detail&aid=1121611&group_id=5470&atid=305470

[rhettinger]

Logged In: YES
user_id=80475

"Break" is a bit of an over-statement.

[birkenfeld]

Logged In: YES
user_id=1188172

This should be addressed by the addition of the hashlib
module in 2.5.