Am 12.10.2013 23:04, schrieb Gregory P. Smith:
> agreed with any of these three.

I'm going for hashlib.pbkdf2_hmac() for now. Right now it's just one
function. We can always add a new module for a high level interface later.

> that also makes sense...
>
> I'd leave hmac.py around through at least 3.6 but going ahead and moving
> the implementation into hashlib in 3.4 makes sense.

That gives us the opportunity th provide a faster implementation based
on OpenSSL's HMAC API http://www.openssl.org/docs/crypto/hmac.html . I'm
also tempted to provide a fast one-shot-wonder function that returns the
MAC as bytes: hmac(name, key, value) -> result

It'd be more consistent with the other hashlib constructors if the one liner was:

hashlib.hmac(hash_name_or_func, key, initial_data).digest() (or .hexdigest() for people who want str rather than bytes).
">

(original) (raw)




On Sat, Oct 12, 2013 at 2:31 PM, Christian Heimes <christian@python.org> wrote:
Am 12.10.2013 23:04, schrieb Gregory P. Smith:
> agreed with any of these three.

I'm going for hashlib.pbkdf2\_hmac() for now. Right now it's just one
function. We can always add a new module for a high level interface later.

\> that also makes sense...
\>
\> I'd leave hmac.py around through at least 3.6 but going ahead and moving
\> the implementation into hashlib in 3.4 makes sense.

That gives us the opportunity th provide a faster implementation based
on OpenSSL's HMAC API http://www.openssl.org/docs/crypto/hmac.html . I'm
also tempted to provide a fast one-shot-wonder function that returns the
MAC as bytes: hmac(name, key, value) -> result

It'd be more consistent with the other hashlib constructors if the one liner was:

hashlib.hmac(hash\_name\_or\_func, key, initial\_data).digest() (or .hexdigest() for people who want str rather than bytes).

-gps