# Independently choose lanes and threads param on Argon2

I'm researching on using Argon2 on a JavaEE server-side application.

I'm a bit reluctant to set the parallelism parameter larger than 1 on a JavaEE environment where threads are supposed to be managed by the application server etc, etc.

One idea is to use the low-level API and set lanes to -lets say- 4 and threads to 1.

In the future, I could set threads to 4 to speed things up or revert back to 1 thread if things don't work out well.

I've done some basic examples with the reference implementation and I've seen setting lanes/threads independently to be working as expected.

Is there any scenario where this would produce incorrect results?

Is there something conceptually "wrong" or "insecure" on setting a high value on lanes but not utilising it with multiple threads? Like giving some advantage to an attacker?

• Well, I presume you cannot deny the use of threats to an attacker, so the attacker may parallelize while you do not. Otherwise, hashing generally works if you get the hash value back :) But there are more knowledgeable people here when it comes to Argon2 so I'll shut up already. – Maarten Bodewes Nov 23 '17 at 19:01
• Thanks for the comment. I'm thinking that the attacker already parallelizes on calculating distinct hashes. Using more lanes would require on more execution units and would increase the performance of a single hash calculation but simultaneously drop the parallelism on calculating distinct hashes. In the end of the day, the attacker's performance on hashes/sec would be the same. Does that makes sense? (I honestly ask...) – Kos Prov Nov 24 '17 at 7:20

There is nothing fundamentally wrong about using fewer threads. It does mean you may not be able to make use of all the memory bandwidth you have, resulting in memory being filled a bit more slowly, but it will not damage the memory-hardness of Argon2. This is not ideal for you as the defender because parallelism is not meant to increase the number of operations you can perform in any given timeslice, but to increase the memory fill rate. A single hardware thread on an x86 CPU even at its maximum clock rate cannot saturate the memory bus. It takes multiple cores to do that. In fact, because it's the fill rate that matters, using more than a few threads on most x86 hardware will actually not speed things up!

The attacker is bound not by the computation rate (in fact, the compression function in Argon2 is very simple), but by the total amount of memory required to calculate the hash. Forcing them to use more execution units would not increase the total cost of the attack nearly as much as a bit more memory.

Benchmarks of single-pass Argon2d using an Intel i7-4500U processor from the paper:

Threads  Cycles/byte  Bandwidth (GB/s)
1        1.3          2.5
2        0.9          3.8
4        0.6          5.4
8        0.6          5.4