Re: scrypt Internet Draft

[Nick Galbreath <nickg@client9.com>]

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 <simon@josefsson.org> wrote:
> Nick Galbreath <nickg@client9.com> 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 <simon@josefsson.org> 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 <nickg@client9.com> 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 <simon@josefsson.org> wrote:
>>>>> Solar Designer <solar@openwall.com> 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