Pursuant to PEP466, this is a backport of Python 3.4's hashlib.pbkdf2_hmac.

Of note in this patch:

* None of the utilities for testing both a python and a C implementation simultaneously were present, so this only tests whichever implementation is available.
* Due to a variety of API changes and missing APIs, the code is not an exact copy-paste, tough luck :-)
* I haven't done docs yet.
* It currently accepts unicode values because the ``y*`` format from Python3 doesn't have any parallel in Python2. I'm not sure whether consistency with the rest of the 2-verse is more important than consistency with a sane way to treat data / the 3-verse.

See also http://bugs.python.org/issue21288 to consider one fix/oversite/addition to the existing API as part of this process. (discuss that there)

by default: use the exact same API as 3.4 if it is suitable for PEP 466 and 2.7.7's needs. the above issue is about fixing a possible oversight; so if it happens in 3.4 it should happen in 2.7.7.

Yup, I've got my eyes on it, if anything lands there I'll include it in this in the 2.7 code, whether it's before or after this patch lands :-)

New patch includes the documentation as well.

The attached patch looks pretty good to me.

I'm still concerned about the unicode issue, but I'm not sure what the right way to fix it is.

I don't think there's any way around it, nor do I think that it actually leaks any meaningful timing.

Sorry, I wasn't concerned from a timing attack perspective here, I was concerned from an "oh my god implicit coercion is terrible" perspective :-)

Oh, gotcha.

Yea I agree, but it's Python 2.x that's par for the course.

Some comments:

 * Python 2.7 ships with OpenSSL 0.9.8 on Windows, so the Python version will always get used on that platform, so it needs to be fast.

 * The iterations loop should use xrange instead of range

 * The .encode('ascii') in _long_to_bin() is not necessary in Python 2

 * Given that _long_to_bin() and _bin_to_long() are only used once in the function, it's better to inline the code directly.

 * bytes(buffer()) should not be necessary in Python 2, since objects with a buffer interface will usually also implement the tp_str slot used by bytes().

Sorry that I join the party rather late.

How about you take my back port from https://bitbucket.org/tiran/backports.pbkdf2/ and remove all Python 3.x related code? :) I spent a lot of time to make the code as fast as possible.

On 19.05.2014 12:24, Christian Heimes wrote:
> 
> How about you take my back port from https://bitbucket.org/tiran/backports.pbkdf2/ and remove all Python 3.x related code? :) I spent a lot of time to make the code as fast as possible.

Could you perhaps compare this to the proposed patch ?

Updated patch applies all of MAL's suggestions. Except the buffer() one, the purpose of the buffer() call is to make it an error to pass a list (or random other types) since you can call bytes() on any object.

As a note, the current code is basically identical to the code in Christain's backport, without the py3k compat.

Looks like there's a debugging turd in the test.

New patch removes the pdb nonsense in the test.

New changeset e4da3ba9dcac by Benjamin Peterson in branch '2.7':
backport hashlib.pbkdf2_hmac per PEP 466 (closes #21304)
http://hg.python.org/cpython/rev/e4da3ba9dcac