[Python-ideas] Add adaptive-load salt-mandatory hashing functions?
Gregory P. Smith
greg at krypto.org
Sun Jun 10 19:56:46 CEST 2012
On Sun, Jun 10, 2012 at 9:11 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Jun 11, 2012 at 1:52 AM, Masklinn <masklinn at masklinn.net> wrote:
> > On 2012-06-10, at 17:28 , Nick Coghlan wrote:
> >> 1. Create an issue on bugs.python.org proposing just the binary
> >> version of pbkdf2 as an enhancement to hmac
> > Although it makes sense from a dependency POV, I'm not sure it's the
> > best place to put it as people in need of knowing about PBKDF2 would
> > be more likely to be browsing hashlib, and — more importantly — PBKDF2
> > isn't a MAC, the usage of hmac underlying it being mostly incidental.
> > If PBKDF2 alone is added, I think putting it in its own module
> > (parallel to hmac) would be cleaner, *that* can be deprecated if
> > more cryptographic hashes of that style (e.g. bcrypt, scrypt) are
> > added later on in the style of md5 -> hashlib.
> Yeah, you're probably right. Either a new module, or else in "getpass"
> (either way, with a cross-reference from hashlib).
> Wherever it ends up, it should also reference hmac.secure_compare for
> a comparison function that doesn't allowing timing attacks to
> progressively discover the expected hash.
I'd just stick it in hmac myself but getpass was also a good suggestion.
Cross reference to it from the docs of all three as the real goal of
adding pbkdf2 is to advertise it to users so that they might use it rather
than something more naive.
hashlib itself should be kept pure as is for standard low level hash
algorithms. It can't have a dependency on anything else.
Even if this doesn't make it into the stdlib in time for 3.3, feel free to
update the getpass, hmac and/or hashlib docs to point to the pbkdf2 module
externally as a suggestion for passphrase/secret hashing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas