search

thebaron / passlib

Automatically exported from code.google.com/p/passlib
Other
0 stars 0 forks source link

scrypt support #8

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by elic%astllc.org@gtempaccount.com on 29 Apr 2011 at 7:17

GoogleCodeExporter commented 9 years ago

Original comment by elic%astllc.org@gtempaccount.com on 3 May 2011 at 7:23

GoogleCodeExporter commented 9 years ago

Original comment by elic@astllc.org on 9 Aug 2011 at 5:28

GoogleCodeExporter commented 9 years ago

Original comment by elic@astllc.org on 12 Sep 2011 at 2:26

GoogleCodeExporter commented 9 years ago 
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).

Original comment by elic@astllc.org on 16 Nov 2011 at 6:57

GoogleCodeExporter commented 9 years ago

Original comment by elic@astllc.org on 18 Apr 2012 at 4:15

GoogleCodeExporter commented 9 years ago 
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?

Original comment by wouter.v...@paylogic.eu on 14 May 2013 at 2:25

GoogleCodeExporter commented 9 years ago 
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

Original comment by elic@astllc.org on 16 May 2013 at 10:33

GoogleCodeExporter commented 9 years ago 
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

Original comment by wouter.v...@paylogic.eu on 23 May 2013 at 8:35

GoogleCodeExporter commented 9 years ago 
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.

Original comment by elic@astllc.org on 26 Dec 2013 at 9:38