-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Developers targeting browser-wasm can use Web Crypto APIs #40074
Comments
Really "only secure"? Or just faster? |
AES is literally only secure with dedicated hardware instructions on modern CPUs. All software implementations are subject to various timing problems that ultimately leak the key to a dedicated attack (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf). |
As part of this work item, we should also verify that |
Looking into support and providing a prototype that works with browser os. |
Implement the browser "native" portion for HMAC on Browser WASM. I also made a few refactoring / simplifications where necessary. Contributes to dotnet#40074
* Use crypto.subtle for HMAC on Browser WASM Implement the browser "native" portion for HMAC on Browser WASM. I also made a few refactoring / simplifications where necessary. Contributes to #40074
Implement the browser "native" portion for AES on Browser WASM. There are two issues to solve .NET's Aes API on crypto.subtle: 1. The .NET API supports streaming while crypto.subtle only supports "one shot" APIs. 2. The .NET API supports multiple padding modes while crypto.subtle only supports PKCS7. To solve these issues, we use the following approach: 1. We only invoke crypto.subtle with complete AES "blocks" of data. This allows us to make assumptions about the padding behavior. 2. To implement streaming, remember the last block of the previous cipher text to use as the IV for the next stream of data. 3. When encrypting, since we have a complete block of data and crypto.subtle uses PKCS7 padding, strip off the last block of cipher text which will always be a full block of padding. 4. When decrypting do the inverse of encrypting - append an encrypted block of padding to the cipher text so crypto.subtle will return the full message as plain text. Other changes: - Make a few refactoring / simplifications where necessary. - SubtleCrypto doesn't support 192 bit AES keys, so no longer support AES-192 on Browser. Contributes to dotnet#40074
* Use crypto.subtle for AES on Browser WASM Implement the browser "native" portion for AES on Browser WASM. There are two issues to solve .NET's Aes API on crypto.subtle: 1. The .NET API supports streaming while crypto.subtle only supports "one shot" APIs. 2. The .NET API supports multiple padding modes while crypto.subtle only supports PKCS7. To solve these issues, we use the following approach: 1. We only invoke crypto.subtle with complete AES "blocks" of data. This allows us to make assumptions about the padding behavior. 2. To implement streaming, remember the last block of the previous cipher text to use as the IV for the next stream of data. 3. When encrypting, since we have a complete block of data and crypto.subtle uses PKCS7 padding, strip off the last block of cipher text which will always be a full block of padding. 4. When decrypting do the inverse of encrypting - append an encrypted block of padding to the cipher text so crypto.subtle will return the full message as plain text. Other changes: - Make a few refactoring / simplifications where necessary. - SubtleCrypto doesn't support 192 bit AES keys, so no longer support AES-192 on Browser. Contributes to #40074 * Use an empty array to create encrypted padding block.
Marks the APIs as supported on Browser, and enables Rfc2898 tests on Browser WASM. Use SubtleCrypto deriveBits API to implement one shot Pbkdf2. Contributes to dotnet#40074
* Enable Rfc2898DeriveBytes on Browser WASM Marks the APIs as supported on Browser, and enables Rfc2898 tests on Browser WASM. Use SubtleCrypto deriveBits API to implement one shot Pbkdf2. * Mark HKDF as supported on Browser and enable tests Contributes to #40074
We've concluded that using the Please see #73858 for more information and refer to the design document for more information about the managed implementation expectations. Where native implementations need to be accessed, they will need to be called via JavaScript interop. |
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 secureSubtleCrypto
implementation act as our cryptographic primitive. On browsers which do not supportSharedArrayBuffer
, 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
Acceptance Criteria
SharedArrayBuffer
SharedArrayBuffer
SharedArrayBuffer
SharedArrayBuffer
Issues to address
The text was updated successfully, but these errors were encountered: