I'm under the impression Argon2 is at least marginally better than scrypt as it has heavily analyzed side channel mitigations and such. Is scrypt better in some other way?
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.
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!