You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing Web Cryptography API allows JavaScript applications to perform cryptographic operations. Because it is implemented by the browser, it is unaffected by side-channel vulnerabilities that are inherent to JavaScript and WebAssembly and can utilize hardware acceleration and advanced security mechanisms.
A major drawback of the existing Web Cryptography API is the lack of support for streaming operations. For example, it is impossible to compute a digest of a message unless the message is stored in a single ArrayBuffer, which is impractical for large messages. Server-side runtimes such as Node.js and Deno provide their own APIs that can efficiently process streams of data, but which are not compatible across runtimes or with browsers.
We solve the above problem by adding support for Streams to the Web Cryptography API. The crypto.subtle.{sign,verify,digest} functions are extended to accept a ReadableStream input; and new EncryptionStream and DecryptionStream classes are added, which are transform stream counterparts to crypto.subtle.{encrypt,decrypt}.
I welcome feedback in this thread, but encourage you to file bugs against the Explainer.
This explainer and the accompanying spec text draft were developed under WinterCG. Although it was always intended to be moved to WICG, the reason we are proposing to move it now is because WinterCG will be dissolved, to be replaced by an Ecma TC which will not be able to incubate proposals for W3C standards such as the Web Crypto API (see wintercg/admin#73).
Although there has been little to no progress in this explainer for some time, this seems to have been mostly because the chartering situation of the Web Crypto API spec was unclear. But now that the Web Crypto API is part of the Web Applications Security Working Group, Cloudflare has said that they will pick it up again (cc @jasnell). @twiss, editor of the Web Crypto API spec, also said he could take over the proposal if needed.
The text was updated successfully, but these errors were encountered:
Introduction
The existing Web Cryptography API allows JavaScript applications to perform cryptographic operations. Because it is implemented by the browser, it is unaffected by side-channel vulnerabilities that are inherent to JavaScript and WebAssembly and can utilize hardware acceleration and advanced security mechanisms.
A major drawback of the existing Web Cryptography API is the lack of support for streaming operations. For example, it is impossible to compute a digest of a message unless the message is stored in a single ArrayBuffer, which is impractical for large messages. Server-side runtimes such as Node.js and Deno provide their own APIs that can efficiently process streams of data, but which are not compatible across runtimes or with browsers.
We solve the above problem by adding support for Streams to the Web Cryptography API. The
crypto.subtle.{sign,verify,digest}
functions are extended to accept aReadableStream
input; and newEncryptionStream
andDecryptionStream
classes are added, which are transform stream counterparts tocrypto.subtle.{encrypt,decrypt}
.Read the complete explainer.
Feedback
I welcome feedback in this thread, but encourage you to file bugs against the Explainer.
This explainer and the accompanying spec text draft were developed under WinterCG. Although it was always intended to be moved to WICG, the reason we are proposing to move it now is because WinterCG will be dissolved, to be replaced by an Ecma TC which will not be able to incubate proposals for W3C standards such as the Web Crypto API (see wintercg/admin#73).
Although there has been little to no progress in this explainer for some time, this seems to have been mostly because the chartering situation of the Web Crypto API spec was unclear. But now that the Web Crypto API is part of the Web Applications Security Working Group, Cloudflare has said that they will pick it up again (cc @jasnell). @twiss, editor of the Web Crypto API spec, also said he could take over the proposal if needed.
The text was updated successfully, but these errors were encountered: