hahaha. I just re-read the RFC and saw the author. Nice to meet you Simon!
I'm mostly offline today (traveling), so I'll hack on the scrypt/crypt format mostly likely tomorrow or the weekend. best, nickg On Tue, Sep 18, 2012 at 3:16 PM, Simon Josefsson <[email protected]> wrote: > Nick Galbreath <[email protected]> writes: > >> Thanks Simon. >> >> And now that I can read it... ;-) >> >> * need more detail on salt and format and allowed characters. For >> some reason the man page on crypt-256/512 is very specific on the >> allowed salt alphabet, etc. > > Sure. > >> * need reference to base64, most likely http://tools.ietf.org/html/rfc3548 >> As I learned the hard way there several, and crypt-256/512 uses a >> very custom one. > > RFC 4648 even. :-) > >> * looking at the name/value pairs, if a single variable, in one order, >> case sensitive isn't so bad. However, I'll re-read Solr's other ideas > > Yeah, I think the N= etc stuff wasn't baked, so other ideas are probably > better. > >> * "where N, r and p are unsigned decimal numbers" this probably needs >> more details on allowable ranges and types, e.g. "positive integers" >> Copying the spec isn't bad here, but I need to think how this can be >> simplified. >> >> N CPU/Memory cost parameter, must be larger than 1, >> >> a power of 2 and less than 2^(128 * r / 8). >> >> r Block size parameter. >> >> p Parallelization parameter, a positive integer >> >> less than or equal to ((2^32-1) * hLen) / MFLen >> >> where hLen is 32 and MFlen is 128 * r. >> >> * needs something on happens on error if parameters are misformed or >> incorrect or out of range. >> >> * I'd add a references section > > Yep. > >> Just made a gitorious account under 'ngalbreath' I'm happy to make >> these changes. > > You have permissions, please go ahead! > > /Simon > >> thanks! >> >> nickg >> >> >> On Tue, Sep 18, 2012 at 11:05 AM, Simon Josefsson <[email protected]> >> wrote: >>> 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
