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?
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
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?
Tired of my customary (Score:1)
No, The Cryptocat Vision statement explains it a lot better.
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?
Sig. Sig. Sputnik
Probably not. Encryption-in-the-DOM doesn't really do much for that (and, anyway, SSL client certificates for authentication do more for that, but almost no one uses them.)
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.
No it doesn't. It's just for crypto between server and client.
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.
You will create keypairs and exchange public keys via a web app. Via the API, you will be able to create digital signatures to help with user verification. This API is not being promoted as a silver bullet for security and privacy, however, when used in conjunction with other browser features like CSP ( http://www.w3.org/TR/CSP/ ) - and I imagine new browser features we still need to figure out (perhaps secure input and reading widgets), we hope to enable more secure web applications. I want to underscore that this API is just the first piece of the pie. Taming and being able to trust the DOM is not going to be easy.
They are never, ever good. Just more stupid crap that stresses me out and makes me tired.
boiled encryption, baked encryption, encription scampi, fried encryption, grilled encryption..encryption cocktails.
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?
Basically it's for when your so paranoid that you fear even your cloud service app provider.
Maybe. The W3C draft lists "Cloud Storage" as one of its use cases, but remember that the app provider is also delivering the JavaScript that runs the decryption and loads up the DOM, so it could intercept the plaintext or decryption key if it wished. It doesn't protect against a malicious cloud service app provider, but it does make it easier for them to secure against data breeches (if their backups were stolen, for instance) and/or rely on 3rd party storage providers.
This has really interesting implications for online privacy, but the more practical/mundane benefits will be in reducing server CPU and making backend storage more secure.
-1, Too Many Layers Of Abstraction
I believe both Firefox and Chrome have support for:
http://www.w3.org/TR/CSP/
Which allows for more control on where code should be loaded from.
Actually I think having crypto as part of the browser is a bigger chance of success then just implementing the crypto in Javascript as some people clearly have already done. You don't want to implement a cryptographically secure pseudorandom number generator in Javascript it will never be secure.
New things are always on the horizon
This. Providing proper crypto primitives in the JS standard library is a good thing, I suppose, but it doesn't solve any (and I do mean any) of the underlying problems with things like CryptoCat. CC actually had quite good crypto primitives (implemented from scrach in JS, but apparently implemented well).
The problem was that every time a user wanted to use CC, they had to download the page (and its JS) from the CC server... and there are so many ways to attack that. An obvious one is to insert a backdoor in the code sent from the server (like what Hushmail did). Crypto primitives in the script library won't help here. Another obvious one is to use SSLStrip to MitM the connection, and inject your own backdoor script along with the server response. Finally, there's attacks against the SSL itself, including things like CRIME.
Essentially, the degree to which you can trust something like CryptoCat is entirely based on the degree to which you trust the server and the connection. It's still host-based security, even though it pretends not to be. No amount of making it easier to implement CryptoCat (which is what you'll get out of this change) is going to make it any more secure.
There's no place I could be, since I've found Serenity...
Thats the point of this API I imagine. If it is included in the browser then there is nothing to intercept and replace. Also it can have some priveledged status where methods can't be overwritten by other scripts.
CSP will be a huge help in reducing attack vectors. Another thing is the key material being unavailable in the DOM. Current JS libraries do not have the option of making all key references opaque and truly hiding the private and secret key material from the DOM. This spec allows the browser to only ever reference key IDs instead of the actual key material.
Um... no. No part of any of the attacks I described requires any interception or replacement of the crypto code (I thought I made that clear). You're still going to have to serve a webpage though. In fact, in order to use these new crypto functions, you're going to have to serve script as well.
I (the attacker, whether via MitM or server control or some other mechanism) can modify that to my heart's content. I don't even have to modify the existing scripts; just inject my own that captures every keystroke sent to the web page and sends them to a server I control (for example). All the crypto in the world won't protect you against that, no matter where it's implemented or what protections it has.
There's no place I could be, since I've found Serenity...
Off-topic, but you can actually already run an entire Linux OS in the browser. Of course, first you have to emulate an x86-based computer to run it on.
You think I'm joking...
There's no place I could be, since I've found Serenity...
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)
Well, there's encryption egg sausage and encryption, that's not got much encryption in it.
What?
I'm interested to see how this would work with the WebRTC API, to allow for browser-based encrypted P2P communications.
I have built a working extension that provides 'window.mozCrypto', which does SHA2 hash, RSA keygen, public key crypto and RSA signature/verification,
No offence, but that's about a hundredth of what SSLeay (the thing that came before OpenSSL) was doing 15 years ago. That's a long, long way to go before you have a general-purpose crypto API usable by web developers.
How you secure your keyring is upto you.
Most users will like the convienence of a single password model, but this time that password never leaves the device you are using. Still at risk to keyloggers just like before.
You could if you wanted secure your own secret keyring using a mixture of methods, such as a combined smartcard, password and biometrics. The biometric code unlocks data on a smartcard, the smartcard provides part of the data to the browser and the password entered into the computer completes all the necessary information needed to gain access to the keyring (that maybe stored on smartcard or on computers).
But the point is you get to decide how secure you want to make your keyring, you no longer have to hope the website you are using is understands how to do things securely. Also each website by default will have their own unique key and it is infeasable to brutre force the authentication.