Thanks for the data. It does seem (to me) that the time to decrypt your vault is <1 sec, so the balance of the time should be attributable to the KDF calculation. All these tests were done with the same production vault (and same device) that was giving you a 3-min unlock time for 56 iterations, right?
If so, then for Argon2id with 64 MiB memory, your device is apparently completing each KDF iteration in about 4 seconds. This would result in about 3 ¾ minutes unlock time for 56 iterations (similar to what you observed), although for a fair comparison to KeePass (which presumably can leverage parallel calculations) you should have used 28 iterations (projected to yield an unlock time of around 2 minutes).
Are you running any other memory-intensive apps on the same device while unlocking your vault?
Can you check how much free/available memory you have (before, during, and after the Argon2id unlock, and after relocking your vault), using resmon? Test this for the 56-iteration KDF, at a minimum.
I can collect perfmon data if you think its of value. But this is not a system resource constraint.
My current system has 16GB of RAM and at this present time only ~53% is consumed. I’d be really surprised if that much memory was consumed when unlocking my vault.
You’re probably right, but it wouldn’t hurt to peak at the changes in memory usage during the 3-minute unlock at least once, to see if you discover something unexpected that may explain why the Argon2id KDF seems slower than it should on your device.
Thank you, yes, I found that PR after I had made the comment above.
What about the addition of the check for else if (kdfConfig.iterations > 10) at Line 432 of crypto.service.ts? Is that on your radar already, or should I post a Github Issue?
And how come all these numerical values (e.g., upper & lower bounds) are hardcoded in different places in the repo, instead of using constants?
CPU: Virtualized i7-12700K (4 Cores provisioned to VMWare VM)
No energy saving mode enabled.
Not sure how much the VM aspect of this matters. I work from VM’s daily for my job. I have no problems with daily tasks including Teams meetings with video streaming, camera feeds etc. FWIW.
It could very well be that the VM is interfering with argon2. Argon2 specifically uses the cache structure of x86 cpus, and if running in a VM, then the cache might be cleared by context switches to other vms. Additionally, it might also be the cause for SIMD not working, I’m not too familiar with VMware, and whether it allows SIMD instructions within VMs. The CPU, browser and OS should support it.
This link references a CPU feature masking configuration used with VMWare ESXi clusters for compatibility purposes. This doesn’t really apply to me since I’m running the Workstation SKU on a single host.
Yes, the host system(s) are my personal machines. I only use VM’s due to requirements for accessing work related resources. This sets the stage for my use case scenario.
Earlier in this thread I mentioned how the specs for a given machine vary as I use different systems at times. Today I’m on a different, slower, VM which happens to be the one that I estimated a ~10 minute duration for unlocking the vaut. Interestingly this VM does not produce the error when using SIMD. The key differences between these two VM’s is the underlyig hardware and Hypervisor version.
These results do reflect that I’m on a less performant system today. But no SIMD related error and KeePass still outperforms with Argon2id on this system.
