[Question] javascript web workers

[ekodo]

Is there a way to use libsodium.js inside a web worker securely?

Because the web worker does not have access to window.crypto.getRandomValues
It would be nice if i could pass the entropy from the main window to the worker, or the worker just can ask the main window for some entropy.

Update
eg: https://github.com/wltsmrz/sjcl-webworker-instructive

[jedisct1]

Hi @ekodo ,

That's exactly the plan: have workers post a request to the main thread, and get back the random bytes.
Unfortunately that hasn't been implemented yet.
Nothing that cannot be worked around, but the fact that the API now becomes asynchronous complicates things a little bit.

[ekodo]

Okay, but for now there is now way (without an update to libsodium/libsodium.js) to use it?
Like you said: a workaround or something

[jedisct1]

Unfortunately not. But pull requests to make it happen would be very welcome!

[ekodo]

The asynchronous is really a problem. Do you have any hint, how you would start?
I'am not sure if this possible without a entropy cache or something else?

Update
first test: https://github.com/ekodo/libsodium-worker-test

@jedisct1 do you think it's a problem to use such a cache (initialize the worker with some entropy, before we start the worker itself)?

[PythonNut]

Is a RNG needed for all operations? I understand it being required for the generation of nonces and salts, but for functions like crypto_pwhash (with a salt that is generated ahead of time on the main thread), it should be fine to operate without a RNG, right?

[jedisct1]

If the module properly loads, it means that the library has been properly initialized and can work as expected.

"depending on the context, only some functions may work, and even functions documented as always successful may now throw an exception under some conditions" would not really inspire confidence.

[PythonNut]

Sounds like a lot of things referenced in the sjcl web worker issue are relevant here as well. Namely, we may just be able to use self.crypto.getRandomValues in the workers according to W3C's spec.

[jedisct1]

Oh, the crypto namespace being exposed in the webworker global scope is great!

I don't know what the status is for other browsers, but yes, at least for Firefox, we can definitely use that.

[jedisct1]

Just noticed that this is already what the current code is doing :)

This works fine on Chrome and Opera, but apparently not yet on Firefox nor Safari.

[BurningEnlightenment]

This works fine on Chrome and Opera, but apparently not yet on Firefox nor Safari.

According to Mozilla Bug Report 842818 it should work on Firefox now, too.

[jedisct1]

That's pretty exciting! Thanks for the heads up!

[buu700]

I'm a little late to this thread, but I have a polyfill that I've been using in production for almost a year that I wouldn't mind contributing under a permissive license (if there's still any interest, given recent browser releases adding support for crypto in workers): https://github.com/cyph/cyph/blob/master/shared/js/cyph/crypto/web-crypto-polyfill.ts

It just needs a 32-byte seed from the main thread's crypto.getRandomValues, which is then used with sodium.crypto_stream_chacha20 to provide a normal synchronous crypto API (example usage).

[webmaster128]

Does anyone have experience with using libsodium.js in a WebWorker in Edge? My .ready Promise is not resolving but without any error.

[buu700]

I'm using it in a worker in @cyph. We've had a lot of issues in the past with things breaking in mysterious ways in Edge (and Safari), particularly in relation to workers, so I wouldn't have been surprised to find an issue here, but I just tested in Edge 16 in BrowserStack and everything works with no issues.

That said, a quick google search found this: support Web Crypto API inside a Web Worker. We're still using the polyfill I linked in my last comment here, which would probably be why we aren't having any issues. (That's pretty lucky; I'm honestly surprised that it's still useful for anything more than supporting ancient versions of Firefox.)

Sounds like there's a bug in .ready since I would expect it to reject when crypto support doesn't exist, which I'll need to fix when I get a chance, but does using my polyfill fix the problem for you? (Compiled version attached.)

web-crypto-polyfill.js

[webmaster128]

The libsodium-based web-crypto-polyfill seems to work, great!

However, since I do not need randomness in my Worker, I created a dummy RNG that produces static bytes for the initialization only. This avoids circular dependencies and the need to seed the worker RNG. If anyone is interested, see https://gist.github.com/webmaster128/694f75a9c51750250ba388811c3a6d88. Note: this fakes a RNG, which may have serious security implications. Use with caution!