W3C Releases First Working Draft of Web Crypto API

From David Dahl's weblog: "Good news! With a lot of hard work – I want to tip my hat to Ryan Sleevi at Google – the W3C Web Crypto API First Public Working Draft has been published. If you have an interest in cryptography or DOM APIs and especially an interest in crypto-in-the-DOM, please read the draft and forward any commentary to the comments mailing list: [e-mail]" This should be helpful in implementing the Cryptocat vision. Features include a secure random number generator, key generation and management primitives, and cipher primitives. The use cases section suggests multi-factor auth, protected document exchange, and secure (from the) cloud storage: "When storing data with remote service providers, users may wish to protect the confidentiality of their documents and data prior to uploading them. The Web Cryptography API allows an application to have a user select a private or secret key, to either derive encryption keys from the selected key or to directly encrypt documents using this key, and then to upload the transformed/encrypted data to the service provider using existing APIs." Update: 09/19 00:01 GMT by U L : daviddahl commented: "I have built a working extension that provides 'window.mozCrypto', which does SHA2 hash, RSA keygen, public key crypto and RSA signature/verification, see: https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ and source: https://github.com/daviddahl/domcrypt I plan on updating the extension once the Draft is more settled (after a first round of commentary & iteration)"

Re:obvious question

[PmanAce]

Just wondering how would you authenticate yourself with your browser? A username password authentication? If not, what would happen if someone else used your browser and had access to everything of yours?

I remember thinking about implementing this...

[InvisibleClergy]

It was because NearlyFreeSpeech doesn't support HTTPS, and I wanted to implement some sort of encryption. So, I figured that my server could encrypt pagelets and send them, and then the client could use a previously-established key to decrypt the pagelets, attaching them to the DOM structure in a logical way. The problem is, since JavaScript explicitly disallows XSS, I couldn't figure out a way to contact a separate key authority server. This meant that however I did it, I'd be (more) vulnerable to a man-in-the-middle attack.

Looking this over, it looks like this specification doesn't solve that issue. I know that key authorities can be compromised, but it's better to require two points of failure rather than one.

Why PKCS#1v1.5?

[cryptizard]

The API has two padding modes for RSA, PKCS#1v1.5 and OAEP. OAEP is provably secure. That is, if the underlying scheme (RSA) is a secure public key cipher, then RSA combined with OAEP is a semantically secure encryption scheme that is resistant to chosen-plaintext attacks. On the other hand, not only is PKCS#1v1.5 not provably secure, it has been known [jhu.edu] for years [cryptograp...eering.com] to be vulnerable to real world attacks.

Most of the time when you see people using it today it is for backwards compatibility, but in this case they are designing a brand new API. Why not go with the one which we know to be secure instead of encouraging the use of a dangerously vulnerable scheme?