29
$\begingroup$

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.

Improve this question
$\endgroup$
4
  • $\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, 2016 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, 2016 at 9:11
  • 2
    $\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, 2016 at 10:13
  • 1
    $\begingroup$ @otus Yes, I'm the person behind LionBSD. I've uploaded the code to LionBSD/lionbsd on GitHub. $\endgroup$
    – fizk
    Jun 19, 2016 at 8:50

3 Answers 3

Reset to default
25
$\begingroup$

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.

Improve this answer
$\endgroup$
13
  • 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, 2017 at 15:49
  • 21
    $\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$
    – omni
    Jan 14, 2017 at 13:32
  • 2
    $\begingroup$ @masi, the attacker's computational power does not really matter for choosing the parameters. The more they have, the larger the proportion of passwords they can break – regardless of your parameters passwords like "123456" will be broken. So you should choose the largest parameters that your system (or the target systems of your software will run on) can feasibly support, so that attackers can break as few passwords as possible. $\endgroup$
    – otus
    Jan 14, 2017 at 14:18
  • 5
    $\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, 2017 at 8:06
  • 3
    $\begingroup$ There is now "Argon2id" which combines the GPU-resistance of 2d with the side-channel resistance of 2i, and is the recommended mode. $\endgroup$
    – BlueRaja - Danny Pflughoeft
    Dec 15, 2018 at 22:28
5
$\begingroup$

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.

Improve this answer
$\endgroup$
4
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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