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:
- Blazor uses their own runtime initialization path and the crypto initialization call is not included in that path (or public)
- Blazor's publish targets limit what files end up in the publish output history
- 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.
- A deadlock that was discovered
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
cc @pavelsavara @maraf @lambdageek @eerhardt
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