Re: scrypt Internet Draft

[Nick Galbreath <nickg@client9.com>]

Hi,

re: " I'm also concerned that too small parameters end up being weaker
than PBKDF2/bcrypt."

The crypt sha-512 spec put specific limits in the crypt format: (from
http://www.akkadia.org/drepper/SHA-crypt.txt). e.g. "The default
number of rounds for both algorithms is 5000", etc.  So assuming we
have some  guidance on minimal parameters (which Solr appears to be
working on), we could add this as well to either the
crypt-API-like-spec or the raw scrypt

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

re: 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.

and

re: "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."

All fair points, but this is a different problem and these issues are
not unique to scrypt and don't change the need for a crypt-like output
format.  But I'm always happy to chat in another thread on auth server
design!

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

re: name-value pairs and parsing

agree with everything Solr said here.  n/v pairs really increases
string parsing complexity == problems.   "rounds" could be
grandfathered-in otherwise I'd just avoid.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

re:  And if we need to add an extra  parameter later, we just pick a
new prefix (call it e.g. $7a$).

Great!.  There is precedent for this as well.  It's not quite the
same, but PHP (and others?) started using $2x$ and $2y$ for bcrypt
variations/bug fixes (http://www.php.net/security/crypt_blowfish.php).

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Happy to help here.

nickg


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