Use crypto.subtle for HMAC on Browser WASM #70745
Conversation
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsImplement the browser "native" portion for HMAC on Browser WASM. I also made a few refactoring / simplifications where necessary. Contributes to #40074 This should probably wait for #70461 to be merged, to ensure both paths (managed and crypto.subtle) are being tested in CI.
|
...stem.Security.Cryptography/src/System/Security/Cryptography/HashProviderDispenser.Browser.cs
Outdated
Show resolved
Hide resolved
| public override void AppendHashData(ReadOnlySpan<byte> data) | ||
| { | ||
| _buffer ??= new MemoryStream(1000); | ||
| _buffer.Write(data); |
There was a problem hiding this comment.
Is this buffering all of the data that's used to compute the hash?
There was a problem hiding this comment.
Yes. There is no other way with SubtleCrypto, currently. The browser-provided implementations are one-shots. You need to give it all of the data up-front. See w3c/webcrypto#73
There was a problem hiding this comment.
This seems like it could be a real pit of failure, especially if we may sometimes use SubtleCrypto and sometimes use the managed implementation based on configuration.
There was a problem hiding this comment.
a real pit of failure
A performance pit of feature because of memory usage? Or something else?
and sometimes use the managed implementation based on configuration.
From my understanding, it is based on the browser's capabilities and even the settings/headers of the page it is hosted in. See https://developer.chrome.com/blog/enabling-shared-array-buffer/ for when we can use SharedArrayBuffer.
There was a problem hiding this comment.
Also, note that this is how the SHA algos are implemented as well in #65966.
There was a problem hiding this comment.
A performance pit of feature because of memory usage? Or something else?
Memory, and then any knock-on effects from that, e.g. exceptions that result from the memory pressure (do the wasm environments enforce any kind of limits on working set size)? I'm just imagining someone downloading a gig of data to hash, expecting it to just stream through, but instead having the whole thing be buffered.
There was a problem hiding this comment.
do the wasm environments enforce any kind of limits on working set size)
WASM is 32-bit, currently, so you have 4 GB of address space to work with, at most. In practice, v8 (Chromium)'s limit is more like 2 GB: https://v8.dev/blog/4gb-wasm-memory. The post is a few years old but I am not aware of that needle moving since then.
There was a problem hiding this comment.
Reality is even more complicated WebAssembly/design#1397 and because of that it can definitely make sense to do the buffering on the js side rather than in managed but I expect most of the uses on this would look more like https://en.wikipedia.org/wiki/JSON_Web_Token than a large binary
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
...em.Security.Cryptography/src/System/Security/Cryptography/HMACHashProvider.Browser.Native.cs
Show resolved
Hide resolved
...em.Security.Cryptography/src/System/Security/Cryptography/HMACHashProvider.Browser.Native.cs
Show resolved
Hide resolved
Implement the browser "native" portion for HMAC on Browser WASM. I also made a few refactoring / simplifications where necessary. Contributes to dotnet#40074
8d59c0a
to
ac72ef8
Compare
|
I believe this PR is ready for review. I'd like to get it merged by the next preview cutoff so HMAC is completely implemented on WASM. |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
The Wasm.Build.Tests failures are due to some blazor tests getting oomkill'ed, unrelated to this PR. They can be ignored here. |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
Implement the browser "native" portion for HMAC on Browser WASM.
I also made a few refactoring / simplifications where necessary.
Contributes to #40074
This should probably wait for #70461 to be merged, to ensure both paths (managed and crypto.subtle) are being tested in CI.This is now merged - so both SubtleCrypto and managed fallback implementations are being tested in CI.