What is the recommended number of iterations for Argon2?

Question

I've recompiled my operating system ("LionBSD" based on FreeBSD) to use Argon2i as the default password hashing algorithm in crypt/libcrypt.

I'm wondering what the recommended number of iterations would be?

As an example, OpenBSD uses 8 iterations of bcrypt by default.

Answer 1

I'm wondering what the recommended number of iterations would be?

Unlike bcrypt or traditional crypt, argon2 does not have a single iteration count, but three parameters affecting the computational cost:

• Number of iterations $t$, affecting the time cost.
• Size of memory used $m$, affecting the memory cost.
• Number of threads $h$, affecting the degree of parallelism.

In addition there are two versions of argon2: argon2d uses data-dependent accesses for presumably stronger tradeoff resistance, while argon2i eschews them to avoid side channel attacks. The latter is recommended for password-hashing.

The argon2 paper gives the following procedure (paraphrased) for determining the parameters you should use:

1. Figure out how many threads you can use, choose $h$ accordingly.
2. Figure out how much memory you can use, choose $m$ accordingly.
3. Decide on the maximum time $x$ you can spend on it, choose the largest $t$ such that it takes less than $x$ with your system and other parameter choices.

I.e. they recommend you run it on your system and decide the largest parameters that match your limits on memory and processor time use.

Answer 2

As was mentioned, cryptography and hashing require a balance between security and usability. If you set the security too high, the user will be put off and avoid using your OS. If you set it too low, hackers will easily crack the system.

As argon2 is quite different from your bcrypt example, it would be wise to follow the strategy in the paper recommended by Otus. Depending on the goals of your system, you may want to have dynamic values rather than static ones.

When the OS is installed, the user could select a value for usability vs security, which represents your maximum t value.

The OS could then detect the available RAM and designate a portion of the RAM for the m value: m=x*RAM.

You could also ask or detect the number of CPUs, Cores, threads, etc and use a portion of those as the h value: h = x*maxthreads.

Then you run a time test across a range of t values until the magic threshold of usability/security is determined.

Save the resultant values in some config file. and add a script to adjust them in the future.

For logging into a high security system, a user may be willing to wait over a second for the validation, but in a high usability system, users want instant gratification so something on the order of 1-50 milliseconds may be required to keep them happy.

A good starting point for m is 0.75 * ( RAM / number_of_users ) a high security system may require a larger multiple than 0.75, but you don't want to go over RAM, because that will greatly slow things down.

For h, the best starting point is the number of cores.

t should then be calculated based on how long it takes to make or verify the hash.

Answer 3

The advise you most often see on this subject seems to be based on finding the maximum settings applicable for a given host. However, most of those answers seem to ignore the fact that the system actually has to do something useful besides hashing passwords using argon2 (or other similar functions).

So rather than assuming Argon2 can use all of the CPU's cores, all of the available RAM, and run at maximum CPU load - you also have determined a baseline for how much the services on your system can afford being interrupted or stalled by doing password hashing using Argon2.

You may find that on a 16 core system with 16 GB of memory, using 128 Mb of memory is fine, but using more than 2 cores with a max load of 10% may be problematic.

No one else but you can make those calculations.