Argon2id

Questions
1

What is recommended argon2id parameters this 2026? Transformation rounds, memory usage, parallelism.

2

The time of “is 100k iterations in 2026 enough” that we had to live with wrt PBKDF2 are over. We can finally have timeless advice:

First select the key derivation time that you can bear. 3-4 seconds is good for disk encryption etc.

Then use as much memory as you can spare taking into account how much you think will be available whenever you’re going to derive the keys. If you have constantly 100 tabs open, you can’t max it out.

Then benchmark key derivation starting from 1, increase it until you’re at the desired key derivation time.

If some time cost t is less than your desired time, and another time cost t+1 is higher than your desired time, select t+1 and lower the memory until key derivation time is good.

If time cost 1 takes too long with your top of the range memory cost, lower memory cost until you hit the desired zone.

Remember, memory cost is king here. That’s what’s capping attacker’s ability to run parallel attacks. Not time-cost which is just iterations; Memory has linear cost for RAM sticks, time cost only has linear cost for seconds and thus, electricity bill. Doubling even an overkill value like 1kWh / password thrice still is fractions of peanuts compared to doubling RAM thrice, from 4GB to 32GB. And at that point, every doubling of crunching power doubles the 300 USD price for RAM alone in the HW.

For parallelism, use either all or all-1 of the threads in your computer. This does not matter. You can set it to say 32 and have a single-core CPU shuffle 32 threads provided there’s enough RAM. It’s just >32 times slower if you ever have to open it on a single core CPU (extra overhead from task switching that also takes time).

But what will ultimately set the security, is your password entropy. Ensure it’s never <90, preferably never <128 bits, and you’re fine.

Use Argon2id in password manager to store other strong passwords.

1 Like
3

Are you user or dev? Are you selecting parameters for yourself or for the application you are developing?

4

A user. Selecting parameters for my self

5

Thank you for the answer

6

@maqp How did you arrive at the 3-4 seconds?

I tried searching for how long Argon2 shall take to compute, and I found the Argon2 paper with instructions for tuning the parameters (section 9). Assuming an application user can configure Argon2’s number of passes, memory usage and number of threads, my interpretation of the instructions is this.

  1. Decide on the maximum tolerable latency (time to compute one hash).
  2. Set the memory usage to the amount of memory the user has at their disposal.
  3. Set the number of threads to what the user can simultaneously run on their device.
  4. Figure out the maximum number of passes that does not cause the latency to exceed the maximum latency.
  5. If the maximum latency is exceeded when the number of passes is 1, decrease the memory usage gradually until the latency no longer exceeds the maximum latency.

I see step 5 as a security decrease though, maybe the user should first sanity-check the maximum tolerable latency they decided on earlier?

However I found RFC 9106, Argon2’s standard, has very different instructions. There are many other different instructions on the internet.

7

Key stretching should not be painful for the user.

Increasing the parameters beyond what is comfortable for the user reduces comfort without providing any significant security benefit.

Instead of increasing the password strength beyond a comfortable level, it’s better to increase the password length—this is much more effective. Increasing the password length exponentially reduces the speed at which a password can be guessed.

8

It’s comfortable time. I’s even recommend 1-2 sec.

9

I agree. I just wonder what the security margin is. If it’s high enough step 5 is no problem. Simultaneously, if we’re considering user pain, how low can users set the latency? I can wait a few seconds to unlock my password manager but why not make it less painful and set it to 10 milliseconds?

10

RFC 9106:

  • Key derivation for hard-drive encryption, which takes 3 seconds on
    a 2 GHz CPU using 2 cores – Argon2id with 4 lanes and 6 GiB of
    RAM.

It’s also just starting a timer and thinking like a normal user. What is tolerable even if you’d have to type the password again once or even twice due to typos. 4 seconds felt like any more and it’s painfully long wait time. 3 was the RFC value for locally run key derivation. So in my projects I aim for something in between, averaging on 3.5 seconds.

I see step 5 as a security decrease though, maybe the user should first sanity-check the maximum tolerable latency they decided on earlier?

Yeah that’s why it’s good to advice on what they should be expecting. But remember, this is password stretching, whatever it can’t do is something the user needs to do in password entropy. It’s a way for user to get away with slightly easier password. That’s all. And it has an added benefit that memory hardness will slow down the rate at which the attacker will scale their rig. Hopefully you can keep increasing RAM in your device at roughly the same % of attacker’s memory, which will then let you keep the password entropy at say 90 bit, when Argon2 manages to stretch it to 110-130 bits compared to raw BLAKE2 hash. I don’t have exact numbers here about how much slower Argon2 is and what kind of bits we’re talking about, but I hope you get where I’m getting at.

1 Like