OpenSSL 1.1 has EVP_PBE_scrypt(). hashlib.scrypt() is a low-hanging fruit for Python 3.6. I have a working patch with some tests. I need to write more tests and documentation:

https://github.com/tiran/cpython/commits/feature/openssl110_scrypt

Rather than PyArg_ParseTupleAndKeywords can you have it use argument clinic?

Also, how about making all arguments other than password be keyword only so
that code calling the function is more clear.  Otherwise it's a bit of
positional argument soup with a lot of integers and potential to invert
password and salt without realizing it.

Argument is easy.

Your second request is a very good idea but also harder to implement. Neither PyArg_Parse nor clinic have a way to declare arguments that required and keyword only but have no default value. I have a workaround but it ain't beautiful.

If clinic doesn't support required keyword only args then don't worry about it for now. :)

Here is a new patch with argument clinic, more tests and required keyword arguments.

It looks that new patch when used like this hashlib.scrypt(b'password') will generate a "an integer is required" exception message which is misleading. I don't test it since I don't get openssl 1.1.

And the phrase "interpreted as buffers of bytes" in the doc may better be "bytes-like objects".

You are right. Let's try this again. How do you like:

>>> hashlib.scrypt(b'', n=2, r=2, p=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: salt is required
>>> hashlib.scrypt(b'', salt=b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: n is required and must be an unsigned int
>>> hashlib.scrypt(b'', n=None, r=2, p=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: scrypt() argument 3 must be int, not None

It looks good. But Christian, may I ask how do you generate the argument clinic? It looks from me that the declaration cannot give you such a format "y*|$y*O!O!O!ll:scrypt". I rerun clinic.py and the .c.h file is altered. Maybe it's better to abandon AC for right now?

It's not a limitation of the argument clinic. PyArg_Parse*() does not support required, keyword-only arguments without a default value. I'm using None as default value, require PyLong_Type and added some extra checks.

Bug in the error message "n must be a multiple of 2." it should say "n must be a power of 2."

Thanks Alex, multiple is the wrong term. The argument 'n' must be 2^m for m > 1.

New changeset d926fa1a833c by Christian Heimes in branch 'default':
Issue #27928: Add scrypt (password-based key derivation function) to hashlib module (requires OpenSSL 1.1.0).
https://hg.python.org/cpython/rev/d926fa1a833c

Benjamin, what's your take on Alex's suggestion?

<Crys> gutworth: Alex_Gaynor has asked me if hashlib.scrypt() can go into 2.7, too. It's a password-based KDF like hashlib.pbkdf2() but more secure than PBKDF2. It requires OpenSSL 1.1.0.
<Alex_Gaynor> gutworth: I think it'd be good if this were approved, for the same reasons as PEP466
<Crys> contrary to PKBDF2 it doesn't make sense to have a pure-Python implementation. scrypt uses ChaCha20 cipher. I don't want to add a cipher to CPython core (possible legal issue) and it's not available in OpenSSL < 1.1.0.

No, scrypt is a simple new feature.  An extension module on PyPI is the appropriate place for that for 2.6 through 3.5.  Wholly unrelated to PEP466.

PEP466 includes hashlib.pbkdf2_hmac(). Any reasoning that includes that surely is applicable to scrypt as well.

Why are we adding scrypt and not argon2 anyway?

On Wed, Sep 7, 2016, at 03:25, Christian Heimes wrote:
> 
> Christian Heimes added the comment:
> 
> Benjamin, what's your take on Alex's suggestion?
> 
> <Crys> gutworth: Alex_Gaynor has asked me if hashlib.scrypt() can go into
> 2.7, too. It's a password-based KDF like hashlib.pbkdf2() but more secure
> than PBKDF2. It requires OpenSSL 1.1.0.
> <Alex_Gaynor> gutworth: I think it'd be good if this were approved, for
> the same reasons as PEP466
> <Crys> contrary to PKBDF2 it doesn't make sense to have a pure-Python
> implementation. scrypt uses ChaCha20 cipher. I don't want to add a cipher
> to CPython core (possible legal issue) and it's not available in OpenSSL
> < 1.1.0.
> 
> ----------
> nosy: +benjamin.peterson
> versions: +Python 2.7
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27928>
> _______________________________________

OpenSSL supports scrypt

On Sep 7, 2016 12:28 PM, "Benjamin Peterson" <report@bugs.python.org> wrote:

>
> Benjamin Peterson added the comment:
>
> Why are we adding scrypt and not argon2 anyway?
>
> On Wed, Sep 7, 2016, at 03:25, Christian Heimes wrote:
> >
> > Christian Heimes added the comment:
> >
> > Benjamin, what's your take on Alex's suggestion?
> >
> > <Crys> gutworth: Alex_Gaynor has asked me if hashlib.scrypt() can go into
> > 2.7, too. It's a password-based KDF like hashlib.pbkdf2() but more secure
> > than PBKDF2. It requires OpenSSL 1.1.0.
> > <Alex_Gaynor> gutworth: I think it'd be good if this were approved, for
> > the same reasons as PEP466
> > <Crys> contrary to PKBDF2 it doesn't make sense to have a pure-Python
> > implementation. scrypt uses ChaCha20 cipher. I don't want to add a cipher
> > to CPython core (possible legal issue) and it's not available in OpenSSL
> > < 1.1.0.
> >
> > ----------
> > nosy: +benjamin.peterson
> > versions: +Python 2.7
> >
> > _______________________________________
> > Python tracker <report@bugs.python.org>
> > <http://bugs.python.org/issue27928>
> > _______________________________________
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27928>
> _______________________________________
>

PEP 466 is explicitly not blanket approval for backporting All The
Things to 2.7. The only justification for pbkdf2 in PEP 466 is to "lower
the barriers to secure password storage and checking in Python 2 server
applications". While scrypt is probably a bit better, applications using
pkbdf2 are still in a much better situation than ones using, e.g., a
naïve salted hash.

There is a self-contained, easily-installable scrypt module on PyPI.