EDIT upon EDIT: After reviewing RFC 9106 overnight, I believe it remains the case that adding parallelism is capable of either adding security or maintaining security while improving speed, but does not reduce security. If it reduced security then the advice from the RFC authors would be quite irrational.
Caveats are two: as described by Quexten, the javascript browser implementation in single-threaded, so potential speed improvement is unavailable; secondly, the consistent advice in the RFC is to set parallelism at twice the number of cores (See section “Parameter Choice”) and to 4 where the cores are not unspecified (presumed to be two). Why on earth would they do this if reducing p improved security?
@bep1995 The question of Argon2id settings was discussed recently in another thread. Your settings for memory and iterations are overkill. Increased parallelism may potentially increase security, or maintain it with more speed; it will not reduce it.
An attacker is not bound by your number of CPUs, cores or threads. Parallelism as a parameter relates to the algorithm’s operation, not the computer itself, and is ordinarily tuned to twice the available cores. On the other hand, both iterations and memory are significant constraints.
Parallelism speeds up the calculation by allowing multiple cores to work in parallel. However, if your computer can only run 8 parallel threads, then there is no benefit (to you) of configuring 16 parallel lanes. However, someone cracking your password using a GPU will benefit from a high parallelism setting, because GPUs generally have thousands of cores available.
Yeah I know that. Maybe I misunderstood what @Mulled7768 said. If I lower the parallelism it will be affect both me and the attacker even if has more cores.
And something else.
The android app it’s much quicker than the web vault on the browser on android. Is that because the web vault it’s optimized to use multiple cores/threads ?? As I said I don’t mind it even if it takes 1 min to open because I open it rarely. But just to know.
Bitwarden’s current implementation of Argon2id only supports multithreading on the Desktop app and the Mobile apps. Therefore, even if you set parallelism=16, only a single thread will be used when unlocking or logging in to the Web Vault or browser extension.
Internally, either a native, or webassembly(single threaded) implementation are used. These are external libraries not implemented but used by the Bitwarden clients.
My best guess is that the computing power on your Android is significantly lower than on your computer, in which case doing a Web Vault login on your Android should be slower than doing a Web Vault login on your computer. However, when you use the Bitwarden mobile app on your Android, it uses multithreading, which speeds up the unlock/login time.
What do you mean? The source code is on GitHub (and linked in @Quexten’s response above).
What kind of info were you looking for then? More something like status on progress towards supporting multithreaded argon2? In that case it’s rather complicated. While webassembly technically can be used to implement multithreaded argon2, (I have an old prototype branch for this around somewhere) it is rather brittle, and needs a lot of work to get working properly. The proper way to do this would be for browsers to support this through a web standard, though this seems to not have much traction: A better password-based key-derivation function in WebCrypto · Issue #59 · WICG/proposals · GitHub
This is hard to say without profiling. It could be that for some reason multithreading - while using the native implementation now - still does not support multithreading. Web/browser defininitely does not.
So, you are saying that maybe the desktop app doesn’t support multithreadind or at least it doesn’t work as it should and that’s the reason the login time it’s the same with the browser, right ??
I lowered the parallelism to 1, so the multithreading will not be a factor and I did some measurements. I also drop the memory to 512 and I kept the iterations to 10.
The desktop app did 4 sec., the browser extension and the web interface did 8 sec.
On the android the app did 14 sec. and the web interface did 24 sec.
So, even with not multithreading there are some differences on the same device.
I tried with 1gb also (with 1 parallelism) and the extension on desktop was slower compared to the web interface, 15 sec. vs 20 sec.
This is my take: Increasing parallelism makes it possible for the user to use higher memory settings while maintaining an acceptable unlock/login delay. If (and only if) the memory is increased in direct proportion to the parallelism increase, there will be a net disadvantage to a GPU-based attacker. Therefore, if your device has surplus memory resources, it makes sense to maximize parallelism.
I have tried to explain this in more detail in an older thread:
So, aside from the iterations, is it better to have 1gb with 10 parallelism for example or 512mb with 1 parallelism ??. I mean… even 512mb its way more than the default, but if i can increase it, why not.
The 512, 1p it’s a little bit faster on the web/browser and a little bit slower on the apps, as it should i guess.
But aside to the performance on my own devices, its better i think to set the parallelism to 1 even with lower memory, because the attacker might be able to use the multithreading to his advantage.
The increased parallelism is supposed to help you login/unlock (such as mobile) faster, the increased memory is supposed to make the attack harder. The attacker with massive number of cores appears to be more limited in memory. You increase the memory, you decrease the number of cores the attacker can use. You decrease the memory, the attacker can increase the number of cores that can be used.
Generally no, because he is limited in memory. That’s why @grb keeps recommending if you increase the parallelism, you should increase the memory. You can read the details of his other posts.