Re: scrypt Internet Draft

[Solar Designer <solar@openwall.com>]

On Tue, Sep 18, 2012 at 05:05:13PM +0200, Simon Josefsson wrote:
> Sorry, the repository was renamed...  see here instead:
> 
> https://www.gitorious.org/scrypt/scrypt-unix-crypt/blobs/master/unix-scrypt.txt

OK, here's a proposed encoding:

$7$Nrrrrrpppppsalt$hash

"N" is one base 64 character for log2(N)
"rrrrr" is little-endian encoding of r (30 bits)
"ppppp" is little-endian encoding of p (30 bits)

There's no need to have a separator character before the salt.  If we
choose to make the salt fixed size, then there will also be no need for
a separator character after it (we'll be like bcrypt in that aspect
then).  I am not sure which way is better.

We also need to decide on whether the salt is an almost arbitrary ASCII
string (not containing '$', ':', '\n') and is passed into
crypto_scrypt() verbatim, or whether it is to be base 64 decoded first.
A third alternative is to declare that the salt may only use the base 64
alphabet, yet is passed into crypto_scrypt() without decoding.

The hash is assumed to be fixed size (perhaps 256-bit, so 43 chars -
this is way more than is actually needed for password authentication,
but I guess some people would be unhappy if it we used less).

Other tunable parameters we could want to export: TMTO defeater
enable/disable flag (will need to decide on its specifics before we can
support the "enabled" mode), Salsa20 core rounds count (support even
counts only? if so, may encode count/2, or maybe even powers of 2 only).
These may be encoded in just one more base 64 char.  We may choose to
include it right away (and have the code reject strings with not yet
supported values).  Alternatively, we can leave these for later, if we
actually need them before there's something entirely different for such
use, and use a new prefix then (e.g. $7a$).

Alexander