Skip to content

Developers targeting browser-wasm can use Web Crypto APIs #40074

@marek-safar

Description

@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.

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.

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

Issues to address

Metadata

Metadata

Labels

Cost:LWork that requires one engineer up to 4 weeksPriority:1Work that is critical for the release, but we could probably ship withoutTeam:LibrariesUser StoryA single user-facing feature. Can be grouped under an epic.arch-wasmWebAssembly architecturearea-System.Security

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions