Use Native Argon2 on Desktop

[quexten]

As issue #4779 points out, parallelism does not work on desktop. Furthermore it is quite slow compared to mobile and cli. This is because it uses the webcryptofunctionservice which uses WebAssembly.

My proposal would be to create a new "electronCryptoFunctionService" extending the webcryptofunctionservice. For argon2 it would talk to the main process via IPC and call a native argon2 implementation (maybe even just a nodecryptofunctionservice instance).

The benefit would be up to 90% reduction in unlock time (going by argon2-browser's benchmarks in the readme) and working parallelism.

[quexten]

Just tested on node v18.12.1, the non-SIMD version of argon2-browser vs native argon2 for Bitwardens max Settings (iterations=10, memory=1GiB, threads=16), and the times on my system are:

1.6 seconds on native, vs 23 seconds on WebAssembly. With the SIMD version it is ~14 seconds, so using the native version where possible would be much better.

[quexten]

For reference, I was also able to compile the PoC threading branch from the argon2-browser repo. For the same settings it was able to run this in 2.3 seconds (with SIMD, threadpool = 16) which is close to native. Maybe it's best to focus on enabling threading in the WebAssembly version first?

[Audionut]

For reference, I was also able to compile the PoC threading branch from the argon2-browser repo. For the same settings it was able to run this in 2.3 seconds (with SIMD, threadpool = 16) which is close to native. Maybe it's best to focus on enabling threading in the WebAssembly version first?

That would seem best, as it brings almost native performance to all of the apps that currently rely on very slow WebAssembly.

After which, targeted performance gains can be made on specific apps.

[dwbit]

Thanks @quexten the team will get back to you shortly 👍

[MGibson1]

Hi @quexten, thanks for these write ups and all your work on improving our KDFs.

I agree with you that web asssembly and mobile should be the leaders in performance improvements -- those are not only the most popular clients, but also the ones suffering from weakest hardware/runtimes.

I feel we'll likely want to make improvements in the desktop space eventually, but we can worry about that when we're in a place that Desktop is more likely to be the kdf pain point vs browser and mobile.

[quexten]

Yeah, I'd be happy to just get the SIMD work for webassembly merged as that gives major improvement for most configurations already. Native desktop is also not on my priority list.

By the way, most mobile phones are currently faster than even fairly high end desktop machines on many configurations since they use natively compiled libraries already which can use simd and multithreading (for parallelism > 1).

[MGibson1]

Good to know about mobile -- I suspected that was the case, but wanted to make it clear that those applications should be the priority, thanks!