Peter Lundin

How do you recoomend that I run it?

Since clients are littered with god knows what software, shouldn't we care about side channels? What about selecting Argon2id as the default with >10 rounds as default. Also I'd lika a button for 2 or 3 seconds. I know I can simply use a calculator, but I can't get a bunch of employees to do it, unless it is -really- simple. I just recognize that many things are a matter of user taste and suggests that more things could be configured through the UI section of the XML-file...

https://crypto.stackexchange.com/questions/39996/does-the-balloon-hashing-paper-deprecate-argon2/40000#40000 Still, Keepass uses only two rounds as the default, why is that? Shouldn't we set it to twelve rounds (with a security margin), two processors, and a bunch of RAM and tune the RAM count until it is sufferable? Also, I'd like a way to configure the 1 second test button to a timeperiod of my choosing, lets say two or three seconds.

Anything around three seconds and below is acceptable for most users. Getting them to use strong passwords is a real challenge with real pushback from a number of sources. So we need to build stronger products to cope with a changing ecosystem. (Which is why I asked to to have the iterations count installation specific and user configurable) I see that we're not getting anywhere on this. Thank you very much for taking your time to answer all of my questions.

Anything around three seconds and below is acceptable for most users. Getting them to use strong passwords is a real challenge with real pushback from a number of sources. So we need to build stronger products to cope with a changing ecosystem. I see that we're not getting anywhere on this. Thank you very much for taking your time to answer all of my questions.

So, how about some middle ground? What do you think of 1.6 seconds on Intel machines and 0.2 on Ryzen machines? 0.2 is still ten times better than 0.02...

Speed today is achieved primarily through concurrency and I consistently buy used computers so I think experience will be pretty much consistent across the board. Iterations count is about creating a cost for someone trying to break the product. 0.02 seconds is not a good cost..

If the key stretching now is faster, then can we get more rounds at least up to the one second threshold? Or better yet: why not make it installation specific and configurable? Also, I vote to have serpent selectable as encryption algo.