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