5 ms·

> because they make them available to you through the web interface. You could have client side javascript that decrypts the files. http://crypto.stanford.edu/

• tlrobinson 16y ago
  And where would the decryption keys come from?
  • bdhe 16y ago
    You generate the key from your username and password and/or store it locally?
    • tlrobinson 16y ago
      function decrypt(cipertext, key) { var req = new XMLHttpRequest(); req.open("POST", "/retrieve_user_key?key="+key); req.send(); // decryption routines return result; } Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place? Of course you also need to trust the desktop Dropbox client. The only (approximately) truly secure way to do this is with an open source client you can inspect and compile yourself (i.e. tarsnap).
      • bdhe 16y ago
        > Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place? I was thinking about the subpoena situation, when the Govt. demands Dropbox to hand over keys. I presume DropBox can definitely send compromised JS or even a malicious client. This is very reminiscent of the whole notion of trusting trust! http://en.wikipedia.org/wiki/Backdoor_(computing)#Reflections_on_Trusting_Trust http://en.wikipedia.org/wiki/Backdoor_(computing)#Reflection...
      • rmc 16y ago
        Reminds me of the Underhanded C Contest, the goal is write a C programme that appears innocent when someone examines the source code, but actually has an intentional malicous action (e.g. stores user data)
      • qntm 16y ago
        > Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place? I don't trust Dropbox to do either of these things, but at least in theory I can examine the JavaScript each time they send it to me, whereas there is no way for me to inspect Dropbox's internal operations to make sure they aren't misusing my key. The problem becomes mechanically verifying that a received chunk of client-side JavaScript is indeed the decryption routine that it claims to be. I think this is a solvable problem.
        • pavpanchekha 16y ago
          Actually, checking that two pieces of code are equivalent is undecideable: http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_of_equivalence http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_... So mechanically checking that Dropbox-supplied code is the decryption routine claimed is impossible.
          • qntm 15y ago
            True. However, we don't need to be able to compare two arbitrary chunks of code. As long as our algorithm provides no false positives, I would settle for something as simple as a checksum.
  • kgo 16y ago
    Hashing your passphrase a million times just most other decryption keys.
• thaumaturgy 16y ago
  You're getting (maybe unfairly) downvoted because the popular opinion in security is that client-side JavaScript anything is worthless in terms of security. Since it's not authenticated in any way by the browser, any successful MITM attack on a connection can feed malicious JavaScript which would request the user's key. Or, a malicious add-on in the browser could do the same. Or, possibly, an XSRF. I'm somewhat skeptical of this because I think that such attacks can be successfully mounted against most other web-related activities. DNS poisoning and self-signed SSL would be enough to phish many people's bank login credentials, and a lot of attacks don't even go to that much trouble. But, anyway, client-side JavaScript for security purposes is supposed to be verboten.
  • JoachimSchipper 16y ago
    The number of people who will find an attack in the middle of a ton of Javascript is much smaller than the number of people who properly handle a certificate warning.
  • bdhe 16y ago
    Thanks for the information. I didn't realize that it is verboten. I presumed it was for efficiency purposes and implementation hassles. I do realize that there are plenty of attack vectors the moment you start trusting JS from a remote website. It was just a proof-of-concept of how Dropbox can still allow you to view files in your browser, but perhaps flash a big warning saying that this is a lot weaker security-wise than locally running your dropbox client. That way they cater to people who are willing to forego a little security for convenience.
• drdaeman 16y ago
  http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...