Is there a specific reason why hashlib.pbkdf2_hmac now has a completely inconsistent API with the rest of the stdlib?  So far the concept in both hashlib and hmac has been to accept hash constructors as parameters.

As such you would expect the API to look like this:

hashlib.pbkdf2_hmac(hashlib.sha256, b'password', b'salt', 100000)

Instead the API now is string based.

This is annoying because a lot of code already in the past exposed a pbkdf2 implementation that allows passing in a hashlib constructor by passing it to HMAC.

If such code now wants to use the stdlib pbkdf2_hmac implementation it has to special case known implementations.  If a non known implementation is found it needs to dispatch to a separate implementation of PBKDF2.

In addition to that there is no nice way to detect if a algorithm is not supported as the exception raised for an invalid algorithm is the same as an invalid parameter for the iteration count (ValueError).

I would propose to change the API to allow hash constructors to be passed in in addition to strings.

This commit shows why the API is problematic: https://github.com/mitsuhiko/werkzeug/commit/c527dcbfb0ee621e9faa0a3a2873118438965800

I agree that this change makes a lot of sense.

A callable wouldn't work for the OpenSSL back end of PBKDF2. The function takes a digest pointer. I have to think about a solution...

Sorry for the brevity, I still don't have proper internet at home.

On 17. April 2014 22:20:36 MESZ, Yury Selivanov <report@bugs.python.org> wrote:
>
>Changes by Yury Selivanov <yselivanov.ml@gmail.com>:
>
>
>----------
>nosy: +christian.heimes, gregory.p.smith
>
>_______________________________________
>Python tracker <report@bugs.python.org>
><http://bugs.python.org/issue21288>
>_______________________________________

On 2014-04-17, 5:02 PM, Christian Heimes wrote:
> Christian Heimes added the comment:
>
> A callable wouldn't work for the OpenSSL back end of PBKDF2. The function takes a digest pointer. I have to think about a solution...
>
> Sorry for the brevity, I still don't have proper internet at home.
>

We can accept only hashlib functions, and continue passing their names 
to the OpenSSL backend. A bit ugly and limited solution (no user-defined 
hash functions) for a better looking API.

Yury

> We can accept only hashlib functions, and continue passing their names 
> to the OpenSSL backend. A bit ugly and limited solution (no user-defined 
> hash functions) for a better looking API.
What I'm doing at the code for my employer is something similar.  There is a PBKDF2 implementation on top of the hmac module.  If a hashlib constructor is detected that OpenSSL implements it dispatches that to the PBKDF2 path in OpenSSL via ctypes.

Ultimately it's the same situation but it does not expose the implementation detail.

I should add that we still support non OpenSSL hashers, but we go a different path.

Armin, FWIW, I don't think it's possible to push this API change in 3.4.

I understand that, but given that this API might be backported to 2.7 I think it should get further review.  Also, this would only be a change to the error case.  Non string arguments are currently being responded to with a TypeError.

I am not proposing to remove the string API, just also allow a hash constructor.

Is anybody interested still to solve the problem? I don't see a viable way to solve the issue in a correct way (*). The hashlib API is not designed to provide sufficient information from a digestmod object. I don't want to include hacks like mapping _hashlib.openssl_sha256 function to SHA256 EVP_MD.

(*) correct means: don't call the function, always reuse the hasher's EVP_MD* context and never fall back to slow path silently.

Yes, I'm definitely still interested in this. I still carry this hack around.

Do you have a proper solution that works within the limits of PEP 247? I could not, hence the existing API.

I have no good solution.  What I do so far is pretty much exactly what was originally reported here: https://github.com/pallets/werkzeug/blob/6922d883ba61c6884fa6cab5bfd280c5a60399af/werkzeug/security.py#L96-L104

I'm working on a hashing algorith v2.0 PEP. New hashing constructors and modules will have an allow_optimization flag and oid attribute. Once finalized and implemented, hashlib.pbkdf2_hmac() will support digestmod and digest constructors that have allow_optimization=True and a valid OID class / module attributes.