Sorry, the repository was renamed... see here instead: https://www.gitorious.org/scrypt/scrypt-unix-crypt/blobs/master/unix-scrypt.txt
/Simon Nick Galbreath <[email protected]> writes: > https://www.gitorious.org/scrypt/scrypt/blobs/master/unix-scrypt.txt > > has vanished! (or I get a 404) > > > > On Tue, Sep 18, 2012 at 5:10 AM, Simon Josefsson <[email protected]> wrote: >> Solar Designer <[email protected]> writes: >> >>> On Tue, Sep 18, 2012 at 08:51:06AM +0200, Simon Josefsson wrote: >>>> We could start it as a parallel effort though. Would you like to help >>>> work on this? I started a document here: >>>> >>>> https://www.gitorious.org/scrypt/scrypt/blobs/master/unix-scrypt.txt >>> >>> FWIW, I am planning to do some research/testing/benchmarking of scrypt >>> for this kind of uses very soon. Chances are that I'll want to make >>> modifications to scrypt proper as a result - probably at least have an >>> optional time-memory tradeoff defeater (a fourth parameter) as briefly >>> discussed with Colin on the crypt-dev list. Naturally, I expect some >>> healthy resistance to any proposed modifications to scrypt, now that >>> it's been around for 3 years and is about to get standardized. Yet I >>> think this is something to discuss and consider. >>> >>> There are also some difficulties with using scrypt as a crypt(3) >>> password hash type. As discussed on crypt-dev, scrypt at <= 1 MB (yes, >>> misuse of it) is not a good replacement for bcrypt, whereas scrypt at >>> much larger memory settings (proper use) should better be used with >>> concurrency limits (not currently found inside crypt(3) implementations, >>> nor in many crypt(3)-using daemons). So the issue is a bit non-trivial. >> >> Yes selecting parameters is difficult. I'm also concerned that too >> small parameters end up being weaker than PBKDF2/bcrypt. Generally, I'm >> not entirely sure how one would use scrypt for authentication services >> -- probably the best is to reserve a chunk of memory and setup a scrypt >> computation service. You would then have no issues up until some >> pre-determined number of authentications/second, that you could >> rate-limit per-user on. >> >>> Speaking of the encoding syntax, I think the key=value,... style of >>> syntax is probably a bad idea. It complicates parsing and brings up >>> unnecessary questions such as whether a parser is supposed to handle >>> keys in the one standard order only or in any order, etc. IIRC, the >>> "rounds=..." thing first appeared in SunMD5, then was reused for >>> SHA-crypt, and well, there were some parsing ambiguities with them. It >>> might be better to just allocate a fixed number of base-64 characters at >>> the start of the string (right after the $7$ or whatever hash type >>> prefix) to correspond to the parameters. And if we need to add an extra >>> parameter later, we just pick a new prefix (call it e.g. $7a$). I used >>> a similar approach in phpass "portable hashes", where the character >>> right after the $P$ prefix holds base-2 logarithm of the iteration >>> count. This is trivial to parse and encode, and there's just one valid >>> encoding. So I suggest that we try not to make things more flexible >>> than we actually need them to be. >> >> Excellent, this was the kind of feedback I was hoping for. I agree. If >> you have a gitorious account and want to help with the document, I'll >> add you. >> >> /Simon
