<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 12, 2013 at 2:31 PM, Christian Heimes <span dir="ltr"><<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 12.10.2013 23:04, schrieb Gregory P. Smith:<br>
<div>> agreed with any of these three.<br>
<br>
</div>I'm going for hashlib.pbkdf2_hmac() for now. Right now it's just one<br>
function. We can always add a new module for a high level interface later.<br>
<div><br>
> that also makes sense...<br>
><br>
> I'd leave hmac.py around through at least 3.6 but going ahead and moving<br>
> the implementation into hashlib in 3.4 makes sense.<br>
<br>
</div>That gives us the opportunity th provide a faster implementation based<br>
on OpenSSL's HMAC API <a href="http://www.openssl.org/docs/crypto/hmac.html" target="_blank">http://www.openssl.org/docs/crypto/hmac.html</a> . I'm<br>
also tempted to provide a fast one-shot-wonder function that returns the<br>
MAC as bytes: hmac(name, key, value) -> result<br></blockquote><div><br></div><div>It'd be more consistent with the other hashlib constructors if the one liner was:</div><div><br></div><div>hashlib.hmac(hash_name_or_func, key, initial_data).digest() (or .hexdigest() for people who want str rather than bytes).</div>

<div><br></div><div>-gps</div></div></div></div>