Argon2id internal iterations vs multiple Argon2id calls ?

Question

TLDR; Is there a security risk if rather than setting the iteration parameter to 12 (for example), we set it to 3 but call the function 4 times?

I'm asking that for 2 reasons:

Firstly, we use SRP protocol where the deprecated SHA1 is replaced by Argon2id inside our PWA (Progressive Web App, so in JavaScript) but Firefox and Google currently discuss to inform user when an operation take too much CPU or RAM. Their goal is to fight against website that doing bitcoin's mining in the background. I don't want this require user's confirmation each time we use Argon2.

Secondly, as we can't known which CPU/RAM are available for the smartphone in JavaScript, we can't known the ideal number of iterations to ideally doing, so we need to find this with the help of a chronometer, we can call Argon2id as many time as possible until 3 seconds elapsed. Of course, we also keep in memory the number of calls used the first time, to do the exact same number of calls the next time we want to compare.

BTW, the last RFC 8018 of January 2017 still recommend PBKDF2 and this KDF is natively supported in browser (WebCrypto API) and faster than any external library, so may be the solution is to not use Argon2 and to use WebCrypto PBKDF2, with the same method of multiple calls until 3 seconds elapsed?

Answer 1

I'm adding my solution here for the record.

Rather than calling multiple times the Argon2d function when the user sign in, we can do something smarter, with a research of the best settings when the user sign up.

We can inform him we will take few seconds to adjust the security while 5 ~ 10 seconds. So if the browser block the process and warn the user, he's already informed and can let continue the process.

Technically, we trying different settings from the lower values (1MB / 1 iteration) until the delay measured require at least 1 second. Then, we could save the settings to use for this user's device. When the user sign in, we simply use the associated settings, and this will not take more than 1 ~ 2 seconds. So in theory this shouldn't be blocked by the browser, and we increase security in following the device's capabilities.

Some real tests:

• Apple iPhone 4S (512MB - 1Ghz): ~1.7s ==> m=1MB,t=1
• Apple iPhone 5 (1GB - 1.3Ghz dual-core): ~1.2s ==> m=4MB,t=1
• Samsung S8 (4 GB, 2.3GHz / 1.7GHz quad-core each): ~1.4s ==> m=24MB,t=2
• NUC i3 (8GB - 1.7Ghz quad-core): ~1.4s ==> m=24MB,t=2

Any feedback are welcome.

Answer 2

I assume you mean the execution time parameter with "iterations". Argon2 was designed to be as memory hard per execution time as possible (along with other critera). If you call Argon2 several times with lower parameters, you are interfering with that goal. Although there are no insecure parameter values, lower values makes an attack easier. That is, the duration of time for a particular hardware of an attack is lower - or the cost of customized hardware to crack the password in a feasible time.

PBKDF2 is not an alternative. The resistance to custom hardware attacks is close to zero, and if you increase the number of iterations to an appropriate number, the same browser problem occurs. If Firefox and Chrome really decide to inform users about time-cosuming and memory-consuming operations to protect mining, then that would be an unsolvable problem for your (and any equivalent) application. Mining is very similar to password hashing (Litecoin and other mining is also memory hard). A good password hashing would therefore always be affected by this measure.