Add key derivation functions (low level only)

[tiran]

I propose the addition of key derivation and key stretching algorithms to cryptography. KDFs are state of the art algorithms to securely hash passwords. The three most well-known algorithms are:

• HMAC based PBKDF2
• bcrypt (blowfish crypt)
• scrypt

OpenSSL has PKCS5_PBKDF2_HMAC() http://bugs.python.org/issue18582 .

OpenSSL also has blowfish but the API is not suitable for bcrypt. The bcrypt algorithm needs one low level function to modify blowfish's internal state. bcrypt also implements its own base64 encoding that is not compatible with standard base64.

scrypt can be implemented on top of OpenSSL's HMAC_SHA256().

IMHO the API should be as low level as possible so 3rd party libraries can be build on top of the APIs. The low level API shall neither handle encodings nor parse crypt(3) / shadow(5) password entries. Password, salt and key shall be bytes. E.g.::

pbkdf2_hmac(hash_name, password_bytes, salt_bytes, iterations, keylen) -> key

[hynek]

I really don’t want to implement anything. I would prefer to vendorize proven scrypt/bcrypt implementations although I’d still prefer this repo to stay C-free. :|

[public]

There are (somewhat) well used Python wrappers for scrypt and bcrypt out there already.

https://pypi.python.org/pypi/scrypt/ http://www.mindrot.org/projects/py-bcrypt/

They both use C extensions rather than CFFI though.

Everyone seems to use their own PBKDF2 implementation and parametrised versions that support more than just HMAC-SHA1 out of the box also seem rare. It's probably simple enough to build into cryptography though. The stdlib already has quite good support for HMAC and various hashes fortunately so there's not much to write.

[hynek]

PBKDF2 is part of OpenSSL fortunately.

The problem in implementing it ourselves is that doing KD in Python slows it down and gives the attackers an edge – at least on CPython. So I’d wrap some trustworthy C code or do nothing.

[dstufft]

FWIW I wrote https://github.com/dstufft/bcrypt which wraps trustworthy C code using cffi and has the same interface as py-bcrypt.

[public]

@hynek Oh of course :) @dstufft Nice, seems like we are only missing a CFFI for scrypt then.

Doesn't quite address how to keep the repo free of C blobs though. It doesn't make life that much simpler if this lib is going to be the primary consumer of a particular dependency and shares maintainers. Unless we stick to only constructions provided by OpenSSL it seems inevitable.

[alex]

At this point we have PBKDF2 and are working on HKDF, so I think we can close this, let's open specific tickets for what we need going forward.