Argon2 WebAssembly SIMD support, multi-threading on Web, Browser, Desktop

[quexten]

PR: #4921

The argon2-browser library in use on the web / browser / desktop versions also compiles for SIMD, but does not include it in the loader scirpt of the NPM package.

My proposal would be to add a custom loader, a modified version of https://github.com/antelle/argon2-browser/blob/master/lib/argon2.js, which loads the SIMD binary if the browser supports it.

It should reduce the unlock times significantly (taken from the argon2 browser repository):

[quexten]

For reference on the max settings (iterations=10, memory=1GiB, parallelism=16) on my machine it would take unlocking time from ~24 seconds to ~13 seconds in Firefox.

[dwbit]

Thanks for the proposal, the team will review 👍

[quexten]

Ok, I have gotten a SIMD branch up and running https://github.com/quexten/clients/tree/feature/argon2-simd

For some reason the argon2-browser demo site has a binary that is ~~~10x~~ faster than the one in the NPM repo (we use). There is an open issue (antelle/argon2-browser#87) on the argon2-browser repo. (was an issue with webpack)

[quexten]

Prototype (still needs major code restructuring and cleanup, and is only tested on web) for threads+simd support:
https://github.com/quexten/clients/tree/feature/argon2-threads

I compiled the branch supporting threads from argon2-browser, and tweaked some things (had to modify the loader, change the threadpool size to 16).

Unlock times for max settings:
No SIMD, No Threads: ~23 seconds
SIMD, No Threads: ~13 seconds
SIMD + Threads: 2.5 seconds

For testing, please use the compiled dist build. In webpack dev mode the unlock times are ~10x slower.

This means there are now 4 WebAssembly binaries in total. Implementations get switched based on what the browser supports (using the wasm-feature-detect library).

[quexten]

One more note: The latest argon2-browser binary from the master branch is 2+ years old. Compiling with the latest emscripten version, with the settings above, the recompilation leads to ~30% faster unlocking (on firefox). I'm not sure which change exactly causes this but it should be worth it to switch to a newer compiled version either way.

[quexten]

@dwbit Forgot to post an update on this discussion. In the meantime I have submitted a corresponding Pull Request here: #4921 . This only implements SIMD support, and replaces the WebAssembly modules with newer, more efficient ones, but reduces the unlock time to ~40% compared to before.

For now, I do not plan on continuing work on multi-threaded argon2, as that is significantly more complex and the current pull-request already gives a significant improvement in unlock time.

[Audionut]

To copy from the forum post. https://community.bitwarden.com/t/recommended-settings-for-argon2/50901/64

On Win11 x64 with edge browser.

[00.935] Params: pass=sdfgwetvw3g$%^G#%$TYVWEWE%, salt=somesalt, time=10, mem=1048576, hashLen=32, parallelism=12, type=2
[00.938] Blocking on the main thread is very dangerous, see [Pthreads support — Emscripten 3.1.32-git (dev) documentation](https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread)
[02.547] Encoded: $argon2id$v=19$m=1048576,t=10,p=12$c29tZXNhbHQ$dZB4elH68FOC5vOJJFxBm7NeFQm7Z+/IxKWdduR62QU
[02.547] Hash: 7590787a51faf05382e6f389245c419bb35e1509bb67efc8c4a59d76e47ad905
[02.547] Elapsed: 1612ms
[02.547] To load another argon2 implementation, please refresh the page first!!

~0.220ms (~15%) slower than KeePass with the same settings, from a browser no less. Impressive!

[MGibson1]

It looks like you're doing some pretty invasive things to the argon2 library we're using. Is it not a better solution to push these changes upstream?

[quexten]

Yes, but it does not look like the library is actively maintained at the moment. I'm happy to do a pull request there but I don't know when / if it will get merged.

I can change the PR back to using the original argon2-browser library, but that would mean having the older, slower binaries (still faster than before with SIMD, but not as fast as could be), and moving the code for checking SIMD availability and loading the SIMD binaries into bitwarden's client libraries.

By the way, the changeset looks large than it is because it includes things like disabling the CI for the fork (which are not relevant to the NPM package). The actually relevant changes are only recompiling the wasm binaries with a newer emscripten version, and adding code to select between SIMD and regular binaries.

[quexten]

@MGibson1 I have undone all non-essential changes on my argon2-browser fork. The only thing somewhat non-essential I left in is the typescript types left in due to the renamed package (the original package has types from DefinetlyTyped). The changeset should be fairly easy to check now: antelle/argon2-browser@master...quexten:argon2-browser:bitwarden

Additionally I have submitted the changes (without the typescript types) to the argon2-browser repo. The PR is here: antelle/argon2-browser#89

But no idea when/if that will get merged due to lack of maintenance on the argon2-browser library.

Let me know if there is anything else I can do.

[MGibson1]

Thank you! I'll make sure these PRs are widely publicized in the company. I'm definitely of the opinion that an upstream PR is the way to go -- especially since no changes are needed other than publicly exposing the feature. Makes me wonder the history of this feature being hidden. Do you know if SIMD was just not available back when the library was active?

[quexten]

I'm definitely of the opinion that an upstream PR is the way to go --

Do beware that the maintainer of argon2-browser mentioned on another project they are also maintaining that they're not working on any open source projects due to a personal situation for the foreseeable future and were looking for active maintainers ~1 year ago, which is why I'm unsure about the changes getting upstreamed.

especially since no changes are needed other than publicly exposing the feature

SIMD can also be used without changes to argon2-browser, as argon2-browser does actually provide hooks for replacing the loading function, but the code for that is... not great.
This is what I did at first: 30db4a2 . I ultimately decided that it makes a lot more sense to move the simd detection to the library.

Do you know if SIMD was just not available back when the library was active?

Firefox and Chrome had SIMD for a quite a while, hidden behind a feature flag (which the argon2-browser still mentions to this day), but Chrome and Firefox only made it available by default in 2021 (https://bugzilla.mozilla.org/show_bug.cgi?id=1695585, https://chromestatus.com/feature/6533147810332672).

Safari still does not support SIMD, though the next beta version supposedly does finally contain SIMD support.

[dwbit]

Closing this one out to tidy up the PR proposal space, let me know if needs to be reopened.