Repository navigation
Developers targeting browser-wasm can use Web Crypto APIs #40074
Description
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.
Design Proposal
The design proposal for how we will enable cryptographic algorithms in .NET for WebAssembly can be found here:
https://github.com/dotnet/designs/blob/main/accepted/2021/blazor-wasm-crypto.md
We intend on providing the most secure implementations of cryptographic algorithms when available. On browsers which support SharedArrayBuffer, we will utilize that as a synchronization mechanism to perform a sync-over-async operation, letting the browser's secure SubtleCrypto implementation act as our cryptographic primitive. On browsers which do not support SharedArrayBuffer, we will fall back to in-box managed algorithm implementations of these primitives.
Where managed algorithm implementations are needed, they can be migrated from the .NET Framework Reference Source.
- https://github.com/microsoft/referencesource/tree/master/mscorlib/system/security/cryptography
- https://github.com/microsoft/referencesource/tree/master/System.Core/System/Security/Cryptography
Work Items
- SHA1
- SHA256
- SHA384
- SHA512
- HMACSHA1
- HMACSHA256
- HMACSHA384
- HMACSHA512
- AES-CBC
- AES-ECB and AES-CFB should throw PlatformNotSupportedException, as they are not available in webcrypto
- PBKDF2 (via Rfc2898DeriveBytes)
- HKDF
Acceptance Criteria
- Integrate into arch-wasm infrastructure
- Ensure a productive development/testing workflow with WebAssembly
- Get all existing unit tests for the algorithms passing in WebAssembly
- Look for opportunities to improve argument validation
- Look for opportunities to modernize the code, such as using Span
- Validate end-to-end scenarios in desktop browsers that support
SharedArrayBuffer - Validate end-to-end scenarios in mobile browsers that support
SharedArrayBuffer - Validate end-to-end scenarios in desktop browsers that do not support
SharedArrayBuffer - Validate end-to-end scenarios in mobile browsers that do not support
SharedArrayBuffer
Activity
jaykrell commentedon Aug 6, 2020
Really "only secure"? Or just faster?
bartonjs commentedon Aug 7, 2020
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 commentedon Aug 31, 2020
As part of this work item, we should also verify that
RandomNumberGeneratoris correctly plumbed down tocrypto.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 commentedon Oct 14, 2020
Looking into support and providing a prototype that works with browser os.
[-]Using Web Crypto APIs for browser-wasm cryptography implementation[/-][+]Web Crypto APIs are available to users targeting browser-wasm[/+]80 remaining items
Use crypto.subtle for AES on Browser WASM (#71501)
Enable Rfc2898DeriveBytes on Browser WASM
Enable Rfc2898DeriveBytes on Browser WASM (#71768)
jeffhandley commentedon Aug 13, 2022
We've concluded that using the
SharedArrayBufferapproach via a worker is not yielding the end-to-end experience or quality necessary to release this integration. As a result, we've changed the scope of what will be included in .NET 7 to no longer include AES-CBC. Additionally, instead of using SubtleCrypto via theSharedArrayBufferto reach the native implementations of other algorithms, we will rely wholly on managed implementations.Please see #73858 for more information and refer to the design document for more information about the managed implementation expectations.
Where native implementations need to be accessed, they will need to be called via JavaScript interop.