Remove AES and SubtleCrypto from WASM

[radical]

We've concluded that using the SharedArrayBuffer approach via a worker is not yielding the end-to-end experience or quality necessary to release this integration. Details and commentary on #72810 show some specific challenges that emerged:

1. Blazor uses their own runtime initialization path and the crypto initialization call is not included in that path (or public)
   • This was addressable
2. Blazor's publish targets limit what files end up in the publish output history
   • This was addressable
3. Chromium is soon going to start limiting SharedArrayBuffer to be available only for cross-origin isolated sites. This will take effect as of Chromium v106.
   • This would require impactful changes to behavior that can't be justified at this stage of the release cycle for this feature
   • For Blazor WebAssembly (hosted), consider enabling cross-origin isolation by default aspnetcore#42114
4. A deadlock that was discovered
   • This specific deadlock was addressable, but it's possible others are lurking
   • [wasm] crypto deadlock fix #73537

These challenges lead to discussions about how often the managed implementations apply vs. the SubtleCrypto implementations. When we laid out the plan to rely on SubtleCrypto through SharedArrayBuffer, we understood this would enable us to use SubtleCrypto in ~90% of scenarios. The plan was to only fall back to managed implementations "on browsers which do not support SharedArrayBuffer. However, with the recognition that the default end-to-end experience disallows use of SharedArrayBuffer broadly, that changed the picture dramatically. We now find ourselves in the situation where 90% or more of scenarios will be relying on the managed implementations, and customers desiring the native implementations must consider tradeoffs for other behavior changes that will occur in their applications. That's not an acceptable outcome.

With these findings and realizations, we're dialing back what we'll be able to support, and we will not rely on a SharedArrayBuffer bridge to invoke async SubtleCrypto APIs from synchronous .NET code. Instead, the supported algorithms will be exclusively supported via managed code and scoped to algorithms without known side channel leaks of the key. Per the original design document:

The implementations of our in-box managed algorithms will be faithful to the appropriate standards. However, we will not pursue FIPS 140-2 or any other certification for them. Our in-box managed algorithm implementations are not intended to be free of side channels.

Here's the net result of the changes to what will be supported.

API	.NET 6	.NET 7 - Planned	.NET 7 - Actual
MD5	Not Supported	Not supported	Not supported
SHA1	Managed	SubtleCrypto (managed fallback)	Managed
SHA256	Managed	SubtleCrypto (managed fallback)	Managed
SHA384	Managed	SubtleCrypto (managed fallback)	Managed
SHA512	Managed	SubtleCrypto (managed fallback)	Managed
HMACMD5	Not supported	Not supported	Not supported
HMACSHA1	Not supported	SubtleCrypto (managed fallback)	Managed
HMACSHA256	Not supported	SubtleCrypto (managed fallback)	Managed
HMACSHA384	Not supported	SubtleCrypto (managed fallback)	Managed
HMACSHA512	Not supported	SubtleCrypto (managed fallback)	Managed
AES-CBC (key sizes 128 + 256)	Not supported	SubtleCrypto (managed fallback)	Not supported
PBKDF2 (via Rfc2898DeriveBytes)	Not supported	SubtleCrypto (managed fallback)	Managed
HKDF	Not supported	SubtleCrypto (managed fallback)	Managed
Asymmetric	Not supported	Not supported	Not supported
Certificates	Not supported	Not supported	Not supported

We do not have plans to try this integration with SubtleCrypto again. Instead, for customers needing native implementations or unsupported algorithms such as AES, we advise they use JavaScript interop to invoke SubtleCrypto directly. That approach will allow the application to be written such that the call can be made in an asynchronous context.

Tasks

• Remove the worker from WasmAppBuilder
• Remove the call from startup.ts
• Remove the DLLImports
• Remove the C# code that is calling this
• Remove the special js-module-crypto in AssetBehaviours typescrypt
• Remove js-module-crypto handling in the SDK (replace it with js-module-threads would be useful)
• Remove managed AES implementation
• Remove the subtlecrypto run of the tests ([wasm] Misc tests related fixes #73884)

cc @pavelsavara @maraf @lambdageek @eerhardt

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Remove the worker from WasmAppBuilder
• Remove the call from startup.ts
• Remove the DLLImports
• Remove the C# code that is calling this
• Remove the special behavior type

cc @pavelsavara @maraf @lambdageek @eerhardt

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-VM-meta-mono
Milestone:	-

[vcsjones]

No rush but.. can someone explain a bit what exactly the intention is here? We found a way to use subtlecrypto without SharedArrayBuffer?

[jeffhandley]

@vcsjones I've updated the issue title and description to capture what we found we need to do. At a high level, we found the SharedArrayBuffer bridge to SubtleCrypto was not yielding the end-to-end experience we had relied on being able to achieve.

[vcsjones]

@jeffhandley is this specific to AES, or is HMAC / PBKDF2 included as well?

Never mind I can't read. It's spelled out nicely in the table.

[vcsjones]

I am curious why AES specifically, when it was my understanding that HMAC and PBKDF were also using the SharedArrayBuffer.

[pavelsavara]

No rush but.. can someone explain a bit what exactly the intention is here? We found a way to use subtlecrypto without SharedArrayBuffer?

There is new interop with JavaScript based on [JSImportAttribute]. It could be used to wrap subtlecrypto's asynchronous API. Applications with requirements to use certified crypto could find a way how to call it asynchronously.

That integration could be independent Nuget package and doesn't have to be in the runtime code. It could also wrap asymmetric algorithms.

[jeffhandley]

I am curious why AES specifically, when it was my understanding that HMAC and PBKDF were also using the SharedArrayBuffer.

Thanks for calling that out, @vcsjones. I've edited the description again to be clearer that what remains supported is now only supported via managed implementations, with that scope being limited to algorithms without known side-channel leaks of keys.