[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scrypt Internet Draft
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.
* 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.
* 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
* "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
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
Just made a gitorious account under 'ngalbreath' I'm happy to make
On Tue, Sep 18, 2012 at 11:05 AM, Simon Josefsson <firstname.lastname@example.org> wrote:
> Sorry, the repository was renamed... see here instead:
> Nick Galbreath <email@example.com> writes:
>> has vanished! (or I get a 404)
>> On Tue, Sep 18, 2012 at 5:10 AM, Simon Josefsson <firstname.lastname@example.org> wrote:
>>> Solar Designer <email@example.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:
>>>> 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.