Implement Web Workers

[Nilos]

Hi guys,

I am thinking about implementing web workers for sjcl. This would make it possible to encrypt large files without blocking the ui. Also ui would not be blocked on older browsers when generating ecc-keys or using kem, unkem, sign or verify for ecc-keys.

The question I would like to ask is if web workers should be a wrapper module around the original sjcl library (as I have implemented it for myself at the moment) or if sjcl should get designated async functions (encryptAsync, decryptAsync, kemAsync, unkemAsync, etc.)

What is your opinion?

[jsmith81]

Can you release the wrapper module that you have already implemented please?

[Nilos]

It is still wired with my own solution. Give me some time please :)

[fbender]

@Nilos, so sjcl can be run as/in a WebWorker without modification (except the message passing part, of course)? Judging by Mozilla Bug 842818, at least getRandomValues() is not available in the worker.

(Edit: Scrub the following paragraph. If I didn't overlook something, as long as the worker instance stays inside a closure and is not accessible outside of a function/object, and registering events is also not possible to outside code, there should be no difference in running sjcl in the main or the worker thread.)

There may be a higher-than-usual security risk with passing unencrypted data (if sjcl fully runs in a WebWorker and plaintext/encrypted data is passed to and retrieved from the worker on the main thread) via worker events: Everybody can subscribe to the events, while for en/decrypting on the main thread, you can encapsulate the sensitive parts within a function (of course, if you want to display the unencrypted data, a script can walk the DOM and find the decrypted data, but that's already more complicated than listening to a single event). So, I'm not sure that simply wrapping the library and doing RPCs is a good solution.

(/Edit)

I'd rather see parts of sjcl running in a worker (like seeding, hashing, signing and whatnot), while de/encryption happens on the main thread. In the case that you actually don't need the data on the main thread (e.g. for displaying), you can handle everything in the worker, but that's up to the implementation (sidenote: Workers can be spawned within workers in Firefox while this does not work in Chrome, so in the latter case, sjcl needs to detect whether it already runs in a worker).

[Nilos]

@Nilos, so sjcl can be run as/in a WebWorker without modification (except the message passing part, of course)? Judging by Mozilla Bug 842818, at least getRandomValues() is not available in the worker. Correct, you need to pass randomness from the main thread.

I was just going to say the thing you added in your Edit :+1:

I would also rather see parts of sjcl running in a worker because I think it is a much cleaner solution. On the other hand when we only put certain things in the worker, the solution gets a lot more complicated. As I already said, I have implemented the wrapper libraries for a private project already, so making them open source should only include small changes.

[flavor8]

@Nilos any update on open sourcing the worker wrapper? I need similar for my open source project...will work on it if you have not had time to.

[Nilos]

There is still one issue regarding entropy where I am not sure about the security. For now what it does is it gets randomness from the main sjcl rng and seeds the worker rng with that randomness. I am not 100% sure if this is valid. Anyhow one could always seed the worker by getting entropy from window.crypto.getRandomValues()

[flavor8]

Is the approach in https://github.com/bitwiseshiftleft/sjcl/issues/36 valid?

FYI, I've been using operative in the past couple hours, which is a nice workers library; it yields nice concise code like this:

    var pbkdf2 = operative({
            hash: function(pass, salt, iters, callback) {
                callback(sjcl.codec.hex.fromBits(sjcl.misc.pbkdf2(pass, salt, iters)));
            }
    }, ['/js/sjcl/sjcl.js']);
    pbkdf2.hash(password, salt, iterations, function(data) { console.log(data); });

Assuming I seed it with entropy from the main thread, that should be valid, right?

[ggozad]

@Nilos window.crypto is not available to web workers. In my implementation of sjcl within web workers I simply create everything that needs random within the main thread and pass it to webworkers.

[Nilos]

I have published some of my code here: https://github.com/Nilos/sjcl-worker Would be happy to see some feedback! Currently it is necessary to add sjcl and requirejs after cloning the repo. You will also have to update the paths to fit your environment.

[hiddentao]

I have also gotten SJCL working within a web worker. The caveat is that the PRNG stuff still need to run in the main browser thread (in order to capture mouse events, etc). I'm thinking of refactoring the code into a new sjcl-worker package with the PRNG main thread setup also included. If you guys also think it's a good idea I can give it a go.

[fbender]

According to [1], you may be able to use self.crypto.getRandomValues within a Worker at least on some browsers.

[1] https://developer.mozilla.org/en-US/docs/Web/API/RandomSource

[hiddentao]

Oh cool, I didn’t know about that.

On 22 January 2016 at 01:43:33, Florian Bender ([email protected]) wrote:

According to [1], you may be able to use self.crypto.getRandomValues within a Worker at least on some browsers.

[1] https://developer.mozilla.org/en-US/docs/Web/API/RandomSource

— Reply to this email directly or view it on GitHub.