crypto is not exposed to webworkers

[willscott]

crypto.getRandomValues API does not appear to be defined in firefox webworkers - at least in firefox 34.

[willscott]

Firefox bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1111150

[willscott]

In addition, we can potentially restructure web workers to hang off of the hidden DOM window, rather than being workers directly created from the JSM context. Finding the different types & definitions in the firefox code base is quite painful.

[ryscheng]

core.crypto?

On Sat, Dec 13, 2014 at 7:53 PM, Will [email protected] wrote:

In addition, we can potentially restructure web workers to hang off of the
hidden DOM window, rather than being workers directly created from the JSM
context. Finding the different types & definitions in the firefox code base
is quite painful.

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[willscott]

There are enough libraries I've encountered that rely on a synchronous crypto.getRandomValues that I'd like to see that here, rather than switch everything to a crypto interface.

[willscott]

Refactored freedom-for-firefox to use
hiddenWindow.Worker, rather than the JSM exposed worker. The same issue with lack of crypto exists in that window as well.

[agallant]

Just noting that this is also blocking e2e working in Firefox - seems like it is stalled at the time being on the Firefox side though.

[iislucas]

Would be great if we could all vote for this issue to be fixed. (signin with mozilla persona account on the bug page and click on the vote button)

[agallant]

To update - this issue is still outstanding. There's relatively little visible progress on the Firefox bug (last comment in February, somebody assigned in March, few cc's since then). freedom.js has a new core.crypto provider meant to facilitate work-around, but unfortunately this requires being able to change the code making the randomness calls (as the provider is async and needs a buffer). For a working example: https://github.com/willscott/freedomjs-anonymized-metrics/blob/master/src/crypto.js

In the case of freedom-pgp-e2e, the calls to getRandomValue occur in a dependency (the end-to-end library itself), and so it's a bit trickier to maintain and refresh a buffer. I'm working on it a bit (https://github.com/freedomjs/freedom-pgp-e2e/tree/soycode-firefoxcorecrypto) as it is blocking @salomegeo (adding key management to uProxy, which obviously needs to work in Firefox).

So, that's the current status - I'll spend a bit more time seeing if it's possible for us to reasonably buffer randomness even without really controlling the getRandomValue calls. I've noticed that Firefox complains if you try to get too much randomness at once, and even when the buffer is full it seems like the polyfill doesn't always satisfy end-to-end. The two other solutions I can picture:

• Prod/help Mozilla in resolving this issue. I don't know much about their development process or if there's someone appropriate to reach out to on this, we don't care about all of window.crypto, just getRandomValue, so that may help.
• Temporarily fork end-to-end so we can properly buffer. I'm leery on this, because we'd prefer not to be directly responsible for the crypto primitive codebase (which is currently pretty well audited/vetted, but our fork would not be so much). I believe we could limit our changes to this file: https://github.com/google/end-to-end/blob/master/src/javascript/crypto/e2e/random/random.js

Opinions on the alternatives are welcome. Thanks!

[willscott]

Just to point out that modules don't need to block on this.
There's a reasonable shim here:
https://github.com/willscott/freedomjs-anonymized-metrics/blob/master/src/crypto.js

As long as you know ahead of time how much randomness you'll go through, you can buffer it in advance and then have the getRandomValue work as expected.

[agallant]

Yeah I've played with that a bit, the problem is the knowing how much randomness ahead of time. The buffer was either inadequate or caused Firefox itself to throw odd errors. It's possibly still doable, I'll take another fresh look in the near future.

[willscott]

You could make a version to return 0's, record how much buffer is requested
in total, then load that much randomness and repeat with real random source

• assuming that the same amount is requested again.

On Tue, Jul 14, 2015 at 3:24 PM, soycode [email protected] wrote:

Yeah I've played with that a bit, the problem is the knowing how much
randomness ahead of time. The buffer was either inadequate or caused
Firefox itself to throw odd errors. It's possibly still doable, I'll take
another fresh look in the near future.

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[agallant]

Actually, a brief revisiting on my outstanding branch has lead to some initial promise (I got the demo to run in Firefox). I'll tweak a bit further and open a pull request for discussion. Thanks!

[agallant]

Our polyfill has been working, but just to note - it looks like there was movement on Bugzilla on this issue about a week ago (https://bugzilla.mozilla.org/show_bug.cgi?id=842818#c60), so we may see a more native resolution and not need to depend on core.crypto for Firefox webworkers in the near future. @dborkan as an FYI since I know you're looking at related issues.

[agallant]

And it looks like the bug is now resolved:

2016-04-12 04:22:40 PDT
Release Note Request (optional, but appreciated)
[Why is this notable]: long-standing request by web devs
[Suggested wording]: Web Crypto API is now available in Workers
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto

Firefox 46 (which I'm assuming will have these changes) is due to be released next week (4/26), so we should be able to close this out after then.