Chromium's implementation follows the Web Cryptography API Editor's Draft.
Be sure to refer to the copy of the spec on github NOT the one hosted on w3c.org.
The version on w3c.org is horribly out of date (as of October 3 2016).
The WebCrypto specification does not mandate any particular algorithms.
At this time Chromium implements all of the algorithms described by the main specification:
Abandoned algorithms
Earlier drafts of the specification contained additional algorithms, which have since been pulled from both the spec and from Chromium's implementation:
href="https://github.com/w3c/webcrypto/issues/27">redefined this as HKDF</a></td>
enabled by default, but has since dropped support.</td>
RSA support
* The modulus length must be a multiple of 8 bits * The modulus length must be >= 256 and <= 16384 bits * When *generating* RSA keys the public exponent must be 3 or 65537. This limitation does not apply when importing keys.
AES support
* The supported key sizes are: * 128 bits * 256 bits * 192 bit AES keys are not supported
EC support
* The supported [namedCurves](https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-NamedCurve) are: * P-256 * P-384 * P-521
Chromium's WebCrypto implementation supports all of the key formats - “raw”, “spki”, “pkcs8”, “jwk”, with the following caveats:
There are differences in DER key format handling between Web Crypto implementations. Where possible for compatibility prefer using “raw” keys or “jwk” which have better interoperability.
When importing/exporting “spki” and “pkcs8” formats, the only OIDs supported by Chromiumare those recognized by OpenSSL/BoringSSL.
Some examples of using WebCrypto can be found in the Blink LayoutTests.
(These can't be run directly in the browser because they access functionality from the test harness, however it gives an idea of how to call the various operations)
Google Chrome measures how commonly WebCrypto algorithms and methods are across web pages. To explore the data use the Chromium feature stack rank dashboard. This counts the number of pageloads that made use of the given feature (internal users can navigate an equivalent histogram using “WebCore.FeatureObserver”). For details on how the metrics are measured read the comment block in CryptoHistograms.h. Here is the correspondence between the feature names found on the Chromium feature stack rank dashboard and WebCrypto's operations/algorithms:
This section is intended for Chromium developers writing patches to address WebCrypto bugs/features.
src/components/webcrypto Contains the actual crypto algorithm implementations (HMAC, ECDH, RSA-PSS, etc.).
src/components/test/data/webcrypto Test data used by src/components/webcrypto. Note that more extensive tests live in LayoutTests, and these will eventually be transitioned there too.
src/third_party/WebKit/LayoutTests/crypto The end-to-end Javascript tests that exercise WebCrypto's crypto.subtle.* methods.
src/third_party/WebKit/public/platform/WebCrypto.h Public interface that defines the Blink <--> Chromium layer
src/third_party/WebKit/Source/modules/crypto The Blink layer (responsible for interacting with the Javascript), and then calling into Chromium side using the WebCrypto interface.
src/third_party/WebKit/Source/bindings/modules/v8/ScriptValueSerializerForModules.cpp Implements the structured clone for CryptoKey
cd src
ninja -C out/Debug components_unittests
./out/Debug/components_unittests --gtest_filter="WebCrypto*"
cd src/third_party/WebKit
ninja -C out/Debug blink_tests
./Tools/Scripts/run-webkit-tests --debug crypto
Unfortunately components_unittests
requires a display to run, even though WebCrypto itself has no such dependency. If you are running from a terminal and get this error the easiest fix is to use Xvfb to create a mock display server (on port 4 in my example)
#Run this in the background....
Xvfb :4 -screen 0 1024x768x24And once it is up, re-run the unit-tests with its display port
DISPLAY:4 ./out/Debug/components_unittests --gtest_filter=“WebCrypto*”