I want to make it even stronger because … i dont know. Because i have the option to do so, because to make it more future proofing ?? Maybe both of that.
Edit. And because i want to know how these settings works.
I totally understand. You want it strongest? Increase the number of words in the passphrase. Increase memory. Increase iterations. Make it the most/longest but still convenient to use (convenience is important; otherwise, you’ll want to give up in the future). Increase parallelism if it makes a difference on your slowest device, typically your mobile.
I already have a six word passphrase, i want to remember it, and with more words it may be difficult !!. And i have already maxed out the iterations.
With 512mb and 1 parallelism im ok even with my mobile device. So, maybe i will stay as i am now.
Maybe 800mb with 4 parallelism it will better but who knows…
I understand about your choices.
More way to remember your longer passphrase: generate the number of words you want to ultimately use (according to @grb, 8 will be quantum resistant, probably with the default parameters). First use 4, then keep adding until you get to the desired length. Typically, you create internal stories for the words anyway, right? So, keeping adding stories.
Thats what i did, i started with 4 words and then i added one more and then one more. I dont think that i will add a 7th word for now at least. Its my first time to a password manager !!
1 Like
In the first case, a 24-GB GPU (e.g., the RTX 4090) can use 220 cores at once (assuming 1 thread per core), and in the second case, they can only use 44 cores. If we (simplistically) assume that a single thread of the 1-GiB task takes twice as long to complete as a single thread of the 512-MiB task, then the first configuration (M=1 GiB, L=10) should result in a computation speed that is faster than the second configuration (M=512 MiB, L=1) by a factor of 220/2/44 = 2.5×.
So to answer your question, between your two options above, the 512-MiB case with a parallelism of 1 would be better.
To take a step back and look at the big picture, everything that you are doing is far beyond what the typical Bitwarden user is doing with their vault, so you are already way ahead of the game. If you enjoy pushing the limits like this, that’s fine, but it’s best not to overthink everything, especially if it is causing you stress! Password managers are supposed to make your life easier, not more difficult.
I just want to find the best settings for me and especially what every setting do, i will not always thinking of that !! I will stuck with the 512mb, 10i, 1p. and with my six word passphrase !!
1 Like
That is my general take also. Ultimately, the p value is a question of efficiency for a user on a particular processor.
What is the basis for this claim please? I believe it would be accurate if it simply omitted the clause about parallelism (“in direct … increase,”)
A problem with asserting that only 44 cores can be used with p = 1 is it assumes the remaining cores are watching the grass grow. More cracking processes (more password options) can be started on the GPU set inversely with the reduction in cores used for a given process. That is, p is effectively neutral for attackers. The constraints are memory and iterations, not cores or p.
It is noteworthy in specific recommendations in RFC 9106 that p is not varied with m (or t). It is varied solely in relation to available cores (p = 2 * cores), for efficiency for the user.
In the general recommendations in the RFC p is specified as 4, and not varied, while m and t are traded. The key advice is that if m is smaller then ideal increase t, iterations, accordingly. Not p (up or down).
I am yet to see evidence that the RFC authors were wrong or careless in their advice.
@bep1995, simplify your life. It is your password that ultimately matters, and a 6-word phrase is very strong. Given your actual memory and iterations, you are at far more risk of many other attack vectors that cracking your password.
I found this comment on security.stackexchange which I think clarifies my comment about GPUs.
If cracking a given password were the entire issue, then yes you want to limit the resources applied. However, if a single password is being tested then you can always do so directly rather than waste time on a GPU – you do not need to “crack” it.
The point is to test multiple passwords – multiple processes using all available cores at all times, however they are limited for a given process.
Can you named some of other attack vectors ?? The most important i can think its a malware, in that case it doesnt matter what kdf settings have or how strong your password is. Its game over.
Malware has different forms and impacts. There are types which amount to confidence tricks (typically investment and romance scams) which may deprive you of money without touching your passwords. There are also various forms of leakage or theft of key data or of passwords themselves. Identity theft gives side access. It is important that the key to your password manager be strong, but is also needs to be copied somewhere. Losing it is inconvenient, to say the least, even without any theft.
Yes, the remaining 16,340 cores will be idle in this scenario. That is the whole premise of Argon2.
More cracking processes (more password options) can be started on the GPU
No, because all GPU cores share the same memory, which is a finite resource (24 GB on the RTX 4090). With 44 cores working simultaneously to hash 44 different password guesses, the amount of memory used (for an Argon2id memory setting of 512 MiB) is 44×(512×220 B) = 23,622,320,128 bytes = 23.622 GB.
Therefore, the amount of unused memory remaining will be only 377,679,872 bytes = 0.378 GB = 360 MiB. Thus, there is not enough memory to start even one additional thread to work on an Argon2id hash that requires 512 MiB of memory!
Thinking about it some more, I think that the memory needs to be increased in a proportion that is greater than the square root of the parallelism increase in order to disadvantage the attacker. The direct proportion is for the purpose of maintaining an approximately fixed unlock/login time for the user.
I am not claiming that they are wrong or careless. Their recommendations would have to be read in context. I do not have the bandwidth currently to undertake a critical reading and analysis of the RFC 9106 text, so I am not going to attempt to reconcile my above assertions with what you’ve concluded from your reading of the RFC. For now, suffice it to say that both of the IRTF’s recommendations for a “uniformly safe option that is not tailored to your application” have the parallelism fixed at 4 (regardless of the number of available cores). It seems that the recommendations in the RFC are tailored to users who just wish to apply some “universally safe” configuration instead of analyzing their scenario and tailoring a configuration that is optimal for their own setup.
“I will stuck with the 512mb, 10i, 1p. and with my six word passphrase !!”
I would prefer 1 GB of memory at 5 iterations 1 with parallelism.
grb, how would you compare these two settings on a technical basis? Are they equivalent?
The official RFC 9106 recommendation is 2 GB of memory at 1 iteration. They have p at 4 in that recommendation. Personally, I prefer p at 1 or 2. With KeePass I use the default of 2 and with Bitwarden I’ve been using 1. Might up mine to 2, but theoretically having it at just 1 does offer some improved cracking resistance. With KeePass I can jack up the memory parameter as much as I like while with Bitwarden it is constrained at a max of 1 GB.
My android phone is 6 years old (xiaomi mi a2).
I will upgrade it in a month or two, then maybe I will increase the memory to 700mb or 800mb and keeping the other settings the same.
The configuration M=512, L=1, T=10 results in 44 cores being used.
The configuration M=1024, L=1, T=5 results in 22 cores being used.
Thus, with the same calculation assumptions as I used above (i.e., each 1-GiB thread takes twice as long to complete as each 512-MiB thread), then with your preferred configuration (M=1024, L=1, T=5), the hash calculation time should be doubled just based on the larger memory, and doubled again based on the smaller number of cores used, but halved due to the lower number of iterations.
Therefore, going from M=512 & T=10 to M=1024 & T=5 (both with L=1) will double hash calculation time for an adversary, while keeping the unlock/login time approximately the same for the user.
1 Like
So is it better to reduce the iterations and increase the memory ?? If you can, remind me what exactly the iterations do ??
And how many cores will be used with this config. (just the number) M=1024, L=1, T=10 and with M=800, L=1, T=10 ?
Im not very good on math !!
Iterations are just a loop. Double the iterations, and the Argon2id hash algorithm will have to execute twice as many times before the hash calculation is complete. Therefore, holding the other settings constant but increasing the iterations, the hash calculation time will increase in direct proportion to the number of iterations; this penalty will apply with equal force to the user (delayed unlock/login time) and to the adversary (slower password cracking).
Assuming cracking is done with a RTX 4090 GPU, which has 24 GB (24,000,000,000 bytes) of memory, each Argon2id hash calculation process will require either 1.074 GB (1,073,741,824 bytes) for M=1024 MiB, or 0.839 GB (838,860,800 bytes) for M=800 MiB. Thus, the number of Argon2id calculations that can be performed in parallel on the same GPU is going to be 22 or 28 (for M=1024 MiB or M=800 MiB, respectively).
If you are keeping parallelism at L=1, then there would be a single core involved in each Argon2id hash calculation, so the attacker would be using 22 cores or 28 cores (for M=1024 MiB or M=800 MiB, respectively). Thus, by reducing the memory setting from M=1024 MiB to M=800 MiB, the time to crack your password will be reduced by approximately 40%.
1 Like
Thank you very much for answer !!
I change it to M=1024, L=1, T=8
Someone In a website about the argon2 settings said that is better to maximize the memory with 1 iteration and then increase the iterations until you will fine with the delay to login (not exactly his words). Is this a good advice ??
Sounds good to me.