Runtime: Developers targeting browser-wasm can use Web Crypto APIs

[marek-safar]

We want to avoid shipping OpenSSL for Browser as that’s not something that aligns well with web nature of WebAssembly as well as it has noticeable impacts on the size of the final app. This would also save us from having to deal with zero-day vulnerabilities as well as support for crypto algorithms which are only secure if they use special CPU instructions (RNG and AES for example).

Using the platform native crypto functions is the preferred solution as it does not have any noticeable size and it’s also the most performant solution. All browser have nowadays support for Crypto APIs which we should be able to use to implement the core crypto functions required by BCL.

Relevant documentation can be found at https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto. The tricky part will be to deal with the async nature of these APIs but we could introduce new async APIs to make the integration easier.

.NET has support for old/obscure algorithms and also other features like certificates which are not relevant in browser space and for them, we would keep throwing PNSE.

[msftbot[bot]]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
See info in area-owners.md if you want to be subscribed.

[jaykrell]

only secure if they use special CPU instructions (RNG and AES for example

Really "only secure"? Or just faster?

[bartonjs]

Really "only secure"? Or just faster?

AES is literally only secure with dedicated hardware instructions on modern CPUs. All software implementations are subject to various timing problems that ultimately leak the key to a dedicated attack (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf).

[GrabYourPitchforks]

As part of this work item, we should also verify that RandomNumberGenerator is correctly plumbed down to crypto.getRandomValues. Right now it's plumbed through /dev/random, which I think the Mono wasm engine ties through correctly, but it's always good to remove indirection and points of failure where possible.

[kjpou1]

Looking into support and providing a prototype that works with browser os.

[msftbot[bot]]

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

[msftbot[bot]]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley
See info in area-owners.md if you want to be subscribed.

---

Issue meta data

Issue content:	We want to avoid shipping OpenSSL for Browser as that’s not something that aligns well with web nature of WebAssembly as well as it has noticeable impacts on the size of the final app. This would also save us from having to deal with zero-day vulnerabilities as well as support for crypto algorithms which are only secure if they use special CPU instructions (RNG and AES for example). Using the platform native crypto functions is the preferred solution as it does not have any noticeable size and it’s also the most performant solution. All browser have nowadays support for Crypto APIs which we should be able to use to implement the core crypto functions required by BCL. Relevant documentation can be found at https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto. The tricky part will be to deal with the async nature of these APIs but we could introduce new async APIs to make the integration easier. .NET has support for old/obscure algorithms and also other features like certificates which are not relevant in browser space and for them, we would keep throwing PNSE.
Issue author:	marek-safar
Assignees:	kjpou1
Milestone:	[object Object]

[juanfranblanco]

@marek-safar Do we have a list of all the crypto libraries that are not supported and the best way to identify if we are running on wasm to fallback to other libraries?

[marek-safar]

@juanfranblanco the best way to verify a library is fully wasm compatible is to enable platform compatibility analyzer for browser-wasm. More details at https://docs.microsoft.com/en-us/dotnet/standard/analyzers/platform-compat-analyzer