A lot of work has already been done by @kothar here: https://bitbucket.org/kevalin-p2p/subtlecrypto
But one of the problem is that the various features of WebCrypto are not supported in every browser (See https://diafygi.github.io/webcrypto-examples), and there are some specific restrictions like with Chrome: WebCryptoAPI support is only enabled for pages loaded over HTTPS, so it would be necessary to have a fallback using the current go implementation when the WebCryptoAPI is not available.
Currently with gopherjs, it's not easy to override a function of the standard library while being able to call the original function, as original overridden functions are renamed "_".
So we need to have a way to override functions, while being able to call the original function. I'm not sure what's the best way to do this.

I had similar thoughts - my initial plan was to create an isomorphic library that could fall back to the stdlib implementation if it couldn't find a browser implementation (or was running natively), but that doesn't help any of the other standard library code which uses crypto. Specifically net/http2 for what I was working on, although I feel like that's a bizarre use case anyway.

A general method for fallbacks like that would probably be useful in many areas, not just crypto.

I guess one way to do it would be to rename the original overridden function e.g. by adding a suffix, allowing it to be called from the overriding function.

I was considering that too. For example, by always adding a prefix such as _ or _GopherJS_ to the identifier being replaced.

My main concern about that was the following. Currently, replaced identifiers get replaced with blank identifiers _. How does that intersect with dead-code elimination?

If we change all _ into non _, does that mean some things that were previously DCEed would no longer be? If so, then we'd want to selectively add the prefix instead of globally. If not, a global prefix is probably fine.

Here is a first POC, only implementing jsSum256 for now: #558

@shurcooL I didn't notice any problem with dead code elimination (on my current project, the generated javascript code has slightly the same size), but I'm not sure if there are other points we can check ?

It'll be very useful for OFACrypto.