4 ms·

You generate the key from your username and password and/or store it locally?

by bdhe 16y ago

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 16y 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.

You generate the key from your username and password and/or store it locally?

by bdhe 16y ago

You generate the key from your username and password and/or store it locally?

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 16y 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.