Issue #8 resolved
Eli Collins
repo owner created an issue
(Imported from Google Code)

SCrypt (http:www.tarsnap.com/scrypt.html) is a key derivation function designed by Colin Percival; and is unique in that it is memory-hard as well as time-hard.

There is currently no password hash scheme based on scrypt, but one could be easily designed.

The main thing preventing support is that SCrypt's underlying KDF routines are not currently available at a python level through any third-party package, so Passlib would have to integrate a copy of the SCrypt source via a builtin C extension. Leading Passlib to the dark side of non-pure python, and the resulting build complications.

Comments (14)

  1. Eli Collins reporter
    (Imported from Google Code)

    As of rd1722888929e, an scrypt-dev branch has been added. This contains a pure-python scrypt implementation (passlib/utils/_slow_scrypt.py). While still in it's early stages and slow, it is functional, so it should be possible to eventually include in passlib without requiring a C extension (though, like bcrypt, one will probably be needed for sufficient security).

  2. Anonymous

    (Imported from Google Code)

    wouter.vanackooy@paylogic.eu wrote:

    I wanted to use hashing with scrypt at my work, so it would be pretty cool if it was included in passlib. I see you already implemented a pure-python version of scrypt, so the next thing would be a version based on the C source, right?
    I can do it for you, so it would be cool if you can then integrate it into passlib?

  3. Eli Collins reporter

    (Imported from Google Code)

    That would be wonderful! My day job has been keeping me rather busy lately, haven't been able to sit down and work on this issue as much as I'd like :(

    I'd certainly welcome some help moving it along, and a C extension providing an scrypt() function was definitely the next step. The scrypt-dev branch currently contains a passlib.utils.scrypt:scrypt() function with the desired call-signature; my plan is to have the module check for a C-extension, and use it if available.

    Just to give a heads up as you're examining the scrypt source... the tgz file over at tarsnap is actually the source for an scrypt-based file encryption tool. A couple of scrypt wrapper projects in other languages mistakenly wrapped the frontend for that tool (located in $SCRYPT/lib/scryptenc); rather than the raw scrypt kdf (located in $SCRYPT/lib/crypto), which is what's needed for passlib.

    Also, one thing that slowed me down was that the scrypt source has multiple backends, which seem to be selected using the Makefile. That, combined with the need for passlib installation to succeed even if the C extension can't be built, makes the needed the setup.py / distutils integration rather complicated. (Not that your patch has solve all of that, just noting some of the obstacles before scrypt-dev is ready for release).

    BTW, I'm maintaining a mirror of passlib's repo over at https://bitbucket.org/ecollins/passlib, which may be easier to fork / contribute to.

    - Eli

  4. Anonymous

    (Imported from Google Code)

    wouter.vanackooy@paylogic.eu wrote:

    Ah cool, then we will take a look at the repo at bitbucket then, since that is indeed a bit easier to contribute to.

    Next week we will start looking at what actually needs to be done, so we will take a good look at the hints you provided and see what to do from there. That means that in the next week you'll see a fork popping up to implement scrypt. We will let you know when we got something for you to review, which hopefully is not too long after we start on the fork :D

    - Wouter

  5. Eli Collins reporter
    • changed Milestone to 1.7

    (Imported from Google Code)

    Since I last looked at it, the scrypt package (https://pypi.python.org/pypi/scrypt/) has exposed the raw scrypt kdf as scrypt.hash(). Depending on this package should be sufficient to permit a workable scrypt hash to be added to passlib. Because of that, marking this issue for the 1.7 release.

  6. Eli Collins reporter

    The main thing holding this back is that I'm still in the process of rearchitecting the CryptContext internals to handle some more complex cases with multi-dimensional work costs, such as scrypt & argon2; as well as figuring out a good way to tune the scrypt default parameters (may have to replicate some of the scrypt cmdline tool's parameter choosing internals).

    I've not been able to give passlib nearly the time investment I would like over the last year, but work is still progressing (though slowly).

  7. Log in to comment