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).
> 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)#Reflection...
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)
> 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.
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.
