[Date Prev][Date Next] [Chronological] [Thread] [Top]

scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash

Just to add some context to Howard Chu's message from Sat, 25 Feb 2017,
I'd like to point out that the scrypt settings chosen for litecoin PoW,
which I think are the ones commercial mining hardware are optimized for, are
some orders of magnitude different than the ones recommended for user
authentication, and are not, in my humble opinion, a sufficient reason to
exclude the scrypt construct from consideration:

 - https://litecoin.info/Scrypt
    uses N = 1024, r = 1, p = 1
    which means using
       1024 * 1 * 1 * 128 = 128 KiBytes bytes of memory
    and doing
       2 * (1024 * 1) = 2 Ki hashing rounds

 - the traditional default values for the parameters are
   N = 16384, r = 8, p = 1 , which means using
       2^16 * 8 * 1 * 128 = 16 MiBytes of memory
   and doing
       32Ki hashing rounds

and these values can be customized (almost) at will to increase both the
computational effort and the memory footprint of the password hashing; e.g.
libsodium's crypto_pwhash_scryptsalsa208sha256 sets N = 2^20 in the
"{OPS,MEM}LIMIT_SENSITIVE" case, leading to a memory occupation of 1GiB and
an hashing rounds count of 2 * 2^20.

As for using SHA-3 defined PRFs for password hashing, while I'm not aware of
any memory-hard construction based on sha-3/shake{128,256} it should be
possible to define a pbkdf2 construction based on the KMAC construct from
NIST Special Publication 800-185 instead of the HMAC one, but this seems a
little bit premature, since the only implementation of KMAC I've found is
the one added to https://github.com/gvanas/KeccakCodePackage 5 days ago with
the "Added a draft implementation of KMAC (SP 800-185 standard)" commit.

Best of all, yours

	lorenzo m catucci