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

Threads  Cycles/byte  Bandwidth (GB/s)