3 ms·

Doesn't scrypt suffer from much of the same parameter selection issues? I know I've had to choose some fairly obtuse values when using scrypt for login in a web

Doesn't scrypt suffer from much of the same parameter selection issues? I know I've had to choose some fairly obtuse values when using scrypt for login in a webapp. In fact, taking a quick look again I find Argon2's "memorySizeKB" and "iterations" make much more sense to me than scrypt's "CostFactor" and "BlockSizeFactor" parameters as it's a lot clearer what's being impacted. I agree with the i-vs-d confusion, but in most cases I think using argon2id as you mentioned should resolve the contention as is already the suggested default in the IETF draft.

lvh 8y ago
Re parameter selection, I’m referring to: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#section-4 https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#sectio... Specifically: > We recommend the following procedure to select the type and the parameters for practical use of Argon2. As opposed to just pick a profile, which, to be fair, the RFC also suggests :) So I guess that’s a fair point, it just feels like as with the i-vs-d thing there’s just more song and dance around it that I wish wasn’t there. The suggestion in the RFC vs published 3rd party recommendations (eg jjarmoc’s NNC reco) are also off by a factor of 100 or so? I’m happy to buy that that’s an unfair subjective impression, but when I was reviewing an argon2id python implementation last week I really just wanted to give people a function that just does “encrypt my damn password already”. Maybe that’s up to the implementation layers job, that’s fine - I did that for txscrypt too and I don’t remember where I got the magic numbers from :) To be clear in case someone else reads this out of context: I am not saying not to use Argon2id!