[Update March 6: it turns out that Firefox does support PBKDF2 on all platforms, but only with SHA-1. I had only tested with SHA-2 hashes so I missed it. I’ve updated the table.]
I tested out all the examples I’ve blogged about here in pretty much every web browser I could get on Linux, Windows, OS/X and Android. I also ran Daniel Roesler’s webcrypto-examples test page on them all. I put what I found in a spreadsheet you can view.
The short version is that RSA-PKCS1-v1_5 for digital signatures, RSA-OAEP for public key encryption, AES-CBC and AES-GCM for symmetric encryption, HMAC, and SHA-1 and SHA-2 hash functions are pretty much universally supported. You can use 1024, 2048 or 4096 bit keys for the public key algorithms, and 128 and 256 bit keys for symmetric encryption safely, but Blink-based browsers do not support 192-bit keys. And in the test browser, spki and pkcs8 export formats are available for key pairs, and raw for AES keys. You can build lots of useful crypography-based applications with those.
The most disappointing omission to me is the lack of any key derivation functions in any current stable browsers I tried. PBKDF2 does work in Chrome Canary everywhere and Opera Developer on Windows, though, so they should be in stable versions pretty soon. I hope other browsers follow soon because there are a lot of cases where we want the user to be able to remember a key instead of store one, and deriving it from a password (or pass phrase) is the only realistic way for a person to do that.
I’m sure a lot of people will be disappointed with the lack of elliptic curve algorithm support, too, but the news is better there. Every browser supports them on at least one platform, at least on their developer early releases, so it’s reasonable to expect them to be universally available soon.
The upshot is that less than three months after reaching Candidate Recommendation status, the Web Cryptography API is already gaining wide and complete support. Microsoft’s Windows 10 preview edition includes a version of Internet Explorer with partial support of the current API (older versions of IE supported an early version of the API that is quite different from the eventual one), so they are clearly planning full support. Apple’s Safari has a prefixed version that looks very compatible with the current specification, though algorithm support and import/export formats are still spotty. So we should be able to use those browsers eventually, too.
Charles Engelke's Blog 
Hi. I can’t access the spreadsheet. You might see a request from me in google drive.
Comment by Jorge Vasquez — March 9, 2015 @ 5:58 pm
Hi. I can’t access the spreadsheet, Google says I’m not authorized.
Comment by jorgepvasquez — March 9, 2015 @ 5:59 pm
The spreadsheet sharing should be working now. I had to copy it to a different account and get a new URL.
Comment by Charles Engelke — March 9, 2015 @ 6:10 pm
Hi, thank you for your work! I see from the spreadsheet that AES-CTR is supported on Chrome/Linux. However, I tried it myself (Chromium 45, updated September 2015), and it looks like support for CTR is missing (AES-CBC works fine).
Chromium’s documentation states that support for AES-CTR under Linux was added with version 46 (October 2015) [1]. Am I missing something or there’s a mistake in the spreadsheet?
Thanks again,
Dario
[1] https://www.chromium.org/blink/webcrypto
Comment by Dario — October 15, 2015 @ 10:56 am
AES-CTR support has been very spotty across browsers, OSs, and even versions. The Web Cryptography Working Group is likely to remove it from the recommendation because it does not appear it will be widely enough supported to qualify for inclusion.
Comment by Charles Engelke — October 15, 2015 @ 11:30 am