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.

  • $\begingroup$ IIRC the heuristic here is "tune the memory parameter as high as you can afford and then tune the (linear) time parameter as much as you can afford." IIRC the memory parameter should increase runtime and memory cost linearly $\endgroup$ – SEJPM Jun 18 '16 at 9:06
  • $\begingroup$ Out of curiosity, where did you get LionBSD? The "site" such as it is has no download or repository links. Or are you the/a person behind it? $\endgroup$ – otus Jun 18 '16 at 9:11
  • $\begingroup$ Note that the work factor in bcrypt isn't the number of iterations. Increasing the work factor by 1 doubles the number of iterations. $\endgroup$ – CodesInChaos Jun 18 '16 at 10:13
  • $\begingroup$ @otus Yes, I'm the person behind LionBSD. I've uploaded the code to LionBSD/lionbsd on GitHub. $\endgroup$ – fizk Jun 19 '16 at 8:50

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.

  • $\begingroup$ Excellent, thanks! I might also allow the user to configure the parameters in /etc/login.conf , and enforce safe minimums. $\endgroup$ – fizk Jun 19 '16 at 8:52
  • 8
    $\begingroup$ @Shackrock, like in the procedure outlined above, you should first pick the largest number of threads and memory, only then iterations through the time it takes with those settings. $\endgroup$ – otus Jan 11 '17 at 15:49
  • 4
    $\begingroup$ This somehow doesn't answer the question for any real-world szenario. The real question is not "what params make sence on MY computer" but rather "what computational power does the possible attacker have at his hands and how should I choose the Argon2 parameters to make an attack economical infeasible". At the end of the day once my encrypted file is stolen the attacker most likely will not use MY hardware to brute force it. So IMHO the question is still not answered. $\endgroup$ – masi Jan 14 '17 at 13:32
  • 1
    $\begingroup$ @otus I'm aware of that but still it IS a question you have to ask when you choose the parameters. E.g. if you're Edward Snowden and you protect files you'll most likely will not use parameters that are "convenient" to use on your laptop. Rather you'll choose the parameters in a way that the one you want to protect the data from - e.g. NSA - with all their comp. power has no easy way to access the data, EVEN IF this means that encrypting/decrypting the data on your laptop now would take a inconvenient amount of time. You choose the params according to the attackers power, not yours. $\endgroup$ – masi Jan 15 '17 at 7:55
  • 2
    $\begingroup$ @masi, if you are the only user and get to choose the password(s), you do not need large parameters. Just generate truly random passwords of sufficient entropy instead. Password hashes are important for securing moderately complex passwords, but if you know you have e.g. 128 bits of entropy you do not need them – other parts of the cryptosystem will be easier to break. $\endgroup$ – otus Jan 15 '17 at 8:06

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.


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.


Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.