Upgrade to the latest MSR crypto library about isomorphic-webcrypto

[phil1618]

@kevlened Besides, the version you mention seems to support concurrent calls. I'm currently using isomorphic-webcrypto in a React Native project and I started to refactor a crypto dependent third party library to remove problematic Promise.all.
Yet, unless concurrent calls are forbidden (which would drastically limit user interactions) it is a lost cause.

I'll try to integrate https://github.com/microsoft/MSR-JavaScript-Crypto and test the result. If I can help, do not hesitate.

[kevlened]

Cryptography is CPU-bound, so long operations will lock the thread. To get around the problem in the browser, the MSR library uses WebWorkers. React-native doesn’t support WebWorkers by default, but you may be able to patch it with a native module. Unfortunately, I don’t know any WebWorker libraries that work out-of-the-box with Expo yet.

An alternative to all this may be using an Expo WebView and proxying calls to that. That would give massively improved performance, not lock the main thread, and automatically get any Safari security updates.

[phil1618]

I agree with your analysis. But I'm not concerned by the performance gain that could be achieved by externalising the computations for the main thread (yet). I'm rather interested in the 1.5 version change mentioned in https://github.com/microsoft/MSR-JavaScript-Crypto#changes-with-version-15. There, we can read:

Now allow concurrent crypto calls of the same type at the same time. Before, concurrent 
crypto operations that shared code would possibly return incorrect results.  
Now, for example, you could perform multiple encryptions at the same time with streaming.

As a matter of fact, currently, you might encountered issues if you try to import keys or decrypt objects concurrently. Typically, if you execute something like:

Promise.all([crypto.subtle.importKey(format, key_1, ...),... , crypto.subtle.importKey(format, key_N, ...)]) 

This is the kind of concurrent calls I was mentioning and how it would be a bad idea to design the application in such a way to avoid occurence of these concurrencies (the Promise.all being a simple way to produce them).

=======

That being said, your advice related to the WebView is very interesting!

I was aware of this mechanism as a way to relax the main thread charge but now, I'm thinking that a WebView could embed the whole crypto library I'm working with... but that is not the subject of the issue :-) Thanks anyway !

[kevlened]

Ah. I assumed you were using Promise.all to try to speed up the crypto operations, but you're just trying to avoid unexpected side effects if someone calls crypto methods concurrently. Let me know if you attempt a migration, I'd love to see it.

If you attempt a WebView-based polyfill, there are two caveats:

1. A WebView needs to be in the root of the App component
2. Crypto.getRandomValues can’t be synchronous

[SanderPeeters]

@kevlened Is there any chance you will update this library with the latest version of the MSR crypto library? I'm tryting to derive a key with the ECDH algorithm but it says: 'unsupported algorithm' whilst in the latest version, it should be supported.
Thanks in advance!