Re: scrypt Internet Draft

[Nick Galbreath <nickg@client9.com>]

ahh, it moved.

https://www.gitorious.org/scrypt/ietf-scrypt/blobs/master/unix-scrypt.txt



On Tue, Sep 18, 2012 at 10:53 AM, Nick Galbreath <nickg@client9.com> wrote:
>  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