Remove AES and SubtleCrypto from WASM #73858
Comments
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
cc @pavelsavara @maraf @lambdageek @eerhardt
|
radical
added
blocking-release
and removed
untriaged
|
No rush but.. can someone explain a bit what exactly the intention is here? We found a way to use subtlecrypto without |
jeffhandley
changed the title
|
@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 |
|
Never mind I can't read. It's spelled out nicely in the table. |
|
I am curious why AES specifically, when it was my understanding that HMAC and PBKDF were also using the SharedArrayBuffer. |
There is new interop with JavaScript based on That integration could be independent Nuget package and doesn't have to be in the runtime code. It could also wrap asymmetric algorithms. |
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. |
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsWe've concluded that using the
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 With these findings and realizations, we're dialing back what we'll be able to support, and we will not rely on a
Here's the net result of the changes to what will be 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
cc @pavelsavara @maraf @lambdageek @eerhardt
|
ghost
added
the
in-pr
ghost
removed
the
in-pr
* Revert 6a02d5d * Revert relevant parts of 4222e69 and AES pieces of 8f75cc9 * Remove Subtle Crypto interop code Fix dotnet#73858
|
Re-opening to backport to 7.0 |
ghost
added
the
in-pr
ghost
removed
the
in-pr
|
@eerhardt are we done here now? |
|
Yes, the last task:
|
|
thanks again for all the help |
ghost
locked as resolved and limited conversation to collaborators
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. Details and commentary on #72810 show some specific challenges that emerged:SharedArrayBufferto be available only for cross-origin isolated sites. This will take effect as of Chromium v106.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 supportSharedArrayBuffer. However, with the recognition that the default end-to-end experience disallows use ofSharedArrayBufferbroadly, 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
SharedArrayBufferbridge 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:Here's the net result of the changes to what will be 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
js-module-cryptoinAssetBehaviourstypescryptjs-module-cryptohandling in the SDK (replace it withjs-module-threadswould be useful)cc @pavelsavara @maraf @lambdageek @eerhardt
The text was updated successfully, but these errors were encountered: