Slashdot Mirror

← Back to Stories (view on slashdot.org)

W3C Releases First Working Draft of Web Crypto API

Posted by Unknown on from the who-do-you-trust dept.

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)"

19 of 63 comments (clear)

  1. Re:obvious question by PmanAce · · Score: 3, Interesting

    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)
  2. Re:obvious question by FilmedInNoir · · Score: 4, Informative

    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
  3. I remember thinking about implementing this... by InvisibleClergy · · Score: 3, Interesting

    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.

    1. Re:I remember thinking about implementing this... by dgatwood · · Score: 2

      Uh... JavaScript has allowed cross-site XHR for going on four years now. It does, however, require appropriate configuration on the server you're contacting. The bigger problem with that design is that if your web hosting server doesn't support HTTPS, how will the third-party server handing out authentication tokens set the token on the server side?

      No, this is better handled through a DH key exchange. Then both sides have a shared symmetric key, and both sides can store it locally (with client-side storage, *not* cookies—you don't want it getting sent in cleartext over the wire). This is actually what the website I'm developing now does. With that solution, sniffing is prevented (or, in my case, injection of unauthenticated non-replay queries to the server; I'm not encrypting the requests, just signing them).

      Of course, none of that prevents active tampering (modifying the JavaScript code to send a copy to a MITM server, for example), which is why HTTPS is still a good idea if at all possible. It would be helpful if more browsers supported SSL with SNI, or if browsers supported SSL with domain keys when working with DNS servers that support DNSSEC, or both.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    2. Re:I remember thinking about implementing this... by InvisibleClergy · · Score: 2

      I was thinking about this originally in January of 2011, and I think I remember finding people mentioning XHR but not finding anything beyond scant mentions. No good "what is this and how do I do" documentation. I was originally thinking a DH key exchange, but that requires you to store it each session, which means each session is vulnerable to MitM, or to use HTML5 things that were not widespread two years ago.

    3. Re:I remember thinking about implementing this... by dgatwood · · Score: 2

      Right. HTML5 local storage is a fairly recent addition. You might also have been able to use a cookie with the "secure" flag set, which means the cookie is sent only over HTTPS connections, but AFAIK can be accessed in JavaScript code locally. I'm not certain whether such cookies are accessible through JavaScript that arrived over unencrypted HTTP, though, so that might not work.

      Regarding cross-origin XHR, it's pretty straightforward. It works just like regular XHR. The only difference is that the server has to send out an Access-Control-Allow-Origin header to indicate that the browser should be allowed to make the request. And the browser makes two requests—a HEAD request to check the ACAO header and an actual request for the URL. As a small caveat, unless they have fixed it recently, Internet Explorer requires you to use a different object, XDomainRequest.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

  4. Re:So, Why? by DragonWriter · · Score: 4, Informative

    Why can't the server do it?

    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.

  5. Re:Client/Server support? by InvisibleClergy · · Score: 5, Insightful

    Chrome will probably put in an update which contains this when nobody's looking. Firefox will update two weeks after Chrome. And IE will take another two years, and their interface for it will be completely broken. Opera will have already had it implemented a month before everybody else, but nobody cares because nobody uses Opera.

  6. Re:Client/Server support? by NevarMore · · Score: 2

    Safari, Chrome, Firefox, and IE will all support this...in slightly different ways.

  7. Re:Client/Server support? by daviddahl · · Score: 4, Insightful

    We have Microsoft, Google and Mozilla all deeply involved in the Working Group. I expect this will be a "webkit" patch, and hopefully land in all webkit browsers. Some initial experimentation has been done by me in Gecko in bug 649154: https://bugzilla.mozilla.org/show_bug.cgi?id=649154

  8. JavaScript and XSS by DragonWriter · · Score: 2

    The problem is, since JavaScript explicitly disallows XSS, I couldn't figure out a way to contact a separate key authority server.

    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.

    1. Re:JavaScript and XSS by spottedkangaroo · · Score: 2

      There are also xss allow headers you can send in the http headers, called "http access control" and you can also get around it with things like JSONP.

      --
      Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
    2. Re:JavaScript and XSS by jedwidz · · Score: 2

      Expanding on that JSONP mention to hopefully save someone a googling...

      XMLHTTPRequest calls are subject to single-origin policy, so can't be used for XSS. However, SCRIPT tags don't have this restriction, even for tags that are dynamically created using JavaScript. JSONP is a trick that leverages this to implement XSS.

      The main limitation is that JSONP can't be used to call non-JSONP web services. So changes to the third-party service may be needed in order to support JSONP.

      As an aside, dynamically loading images cross-domain is also permitted. Not useful for the current discussion though.

  9. Re:Client/Server support? by Archenoth · · Score: 2

    I love how hilariously likely that comment is, but it also makes me kinda sad since I use Opera. :(

    --
    The arch foe.
  10. Re:obvious question by daviddahl · · Score: 2

    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.

  11. Re:obvious question by jamiesan · · Score: 2

    boiled encryption, baked encryption, encription scampi, fried encryption, grilled encryption..encryption cocktails.

  12. MashSSL by flankenstein · · Score: 2
    Why not use MashSSL? That seems like a simpler and better solution.
  13. Why PKCS#1v1.5? by cryptizard · · Score: 3, Interesting

    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?

  14. Re:It's not a working draft... by daviddahl · · Score: 2

    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)