W3C Releases First Working Draft of Web Crypto API 63
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: public-webcrypto-comments@w3.org"
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 (Score:4, Informative)
Basically it's for when your so paranoid that you fear even your cloud service app provider.
For example, you go and use Cloud Doc Editor and write some docs and save them locally...
But what about the remote server? What's it doing with that data? Is it making copies?
Could it know you write erotic fan-fic about Captain Picard having sex with Rainbow Dash?
Re:So, Why? (Score:5, Informative)
If the server does the encryption, then the server has to see the unencrypted content.
If the client does the encryption, the server doesn't have to see the unencrypted content.
Also, if the server does the work and you have a million clients, then the server has to do a million units of work rather than the clients each doing one unit of work. This can make the server more impacted by traffic spikes and provide a less-consistent and sometimes lower-quality user experience than just offloading that work to the client.
Alternatively, its more expensive (more CPU = more $$) for the server operator, who often owns the app. So there's an incentive to build apps in a way that the work is offloaded.