Do not reference these kinds of docs whenever you need practical, actionable advice. They serve their purpose, but are for a completely different kind of audience.
For anyone perusing this thread, your first resource for this kind of security advice should probably be the OWASP cheatsheets which is a living set of documents that packages current practice into direct recommendations for implementers.
Here's what it says about tuning Argon2:
https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
It's been a couple years since I've looked but the track record of OWASP for cryptography advice has been pretty dismal.
Do you have a better recommendation?
I feel bad for OWASP. They're doing the lords work, but seem to have a shoestring budget.
The OWASP ASVS appendix on Cryptography is one of the best and concise resources I know for this kind of thing: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Append...
This is just a random list of links to standards and summary tables, some of which are wrong (urandom vs. random, for instance). The "A/L/D" scoring makes very little sense. CBC is legacy-allowable and CTR is disallowed; "verification of padding must be performed in constant time". For reasons passing understanding, "MAC-then-encrypt" is legacy-allowable. They've deprecated the internally truncated SHA2's and kept the full-width ones (the internally truncated ones are more, not less secure). They've taken the time to formally disallow "MD5 and SHA1 based KDF functions". There's a long list of allowed FFDH groups. AES-CMAC is a recommended general-purpose message authenticator.
This is a mess, and I would actively steer people away from it.
I’d wager that something like 90% of developers who look at that page should close the tab instead of reading any of it.
If you’re building a system and need crypto… pick the canonical library for the ecosystem or language you’re working in. Don’t try to build your own collection of primitives.
https://argon2-cffi.readthedocs.io/en/stable/parameters.html