Slashdot Mirror
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: 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)"
Anyone know which browsers & httpd's are planning support for this soon? Webkit?
(that I'm too lazy to read the article for) is does this mean an end to passwords, and the beginning of proper identity management in the browser. I would love to authenticate myself once to the browser, and then have it negotiate identities with each website.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Eventually at some point I would hope there's a backend server the app is talking to.
Why can't the server do it? Thin Client Fat Client... Why are you making my client fat Sir?
Sig. Sig. Sputnik
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.
Microsoft releases less secure copy of W3C Web Crypto API already implemented in Internet Explorer 10 called SecureXaml while citing the changes as "features".
JavaScript doesn't "explicitly disallow XSS". Most browsers (through implementations of the still-in-draft Content Security Policy, and, for IE, additionally through its own "XSS filter") include means of restricting XSS, but those browsers also allow pages to control whether and how those XSS-limiting features are applied.
They are never, ever good. Just more stupid crap that stresses me out and makes me tired.
Douglas Crockford tends to disagree. And he's not alone.
How do they mitigate these inherent security problems of the JavaScript platform in the API draft? With XSS, I can always overwrite the browser's crypto API object, replacing it with a rogue implementation.
My understanding has been that JavaScript in its present form is not a viable platform for cryptography.
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 for years 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?
... it's a bunch of random thoughts. Most of the current "draft" consists of "TBD" or "here are some ideas that need to be fleshed out". This looks like it's years from reality, at which point it'll have turned into another CDSA-sized monstrosity containing the union of every feature requested by every vendor ever.
Every time I read a story like this, I feel like we're getting closer and closer to the web browser implementing every feature of the OS.
Soon they will decide that they need a better way to manage tabs and build in a primitive tab manager, vaguely reminiscent of a window manager.
At some point there will be a page where you can enable and disable different extensions.
Some extensions will then open their own tab that will be handled by the tab manager.
Eventually we will decide that html is too restrictive, and someone will make an extension that translates some other markup language into html.
And so on, and so forth.
I'm interested to see how this would work with the WebRTC API, to allow for browser-based encrypted P2P communications.
Couldn't see in the draft anything about crypto exportation restrictions. Would it be safe to use a browser supporting this in Iran?
sorry if you cant use aes then forget it....
Mandy Moore regrets every day of her life for discounting his prom request.