Basically trust Dropbox about as much as you trust email, if it matters encrypt it locally
Basically trust Dropbox about as much as you trust email, if it matters encrypt it locally
I'm sorry, but I don't follow.
For all bit-identical copies of a file, the secure hash will be the same. For all copies of that file encrypted with the same symmetric encryption key, the same property holds. Encrypt it with AES-256 using a shared key, and all users can still take advantage of the LAN copies and de-duping that Dropbox supports for unencrypted files.
Now, if you want full asymmetric (RSA, PGP, whatever) encryption of files with per-user keys and fast LAN copies/de-dupling of the plaintext version, you're of course out of luck. That's not a failing of Dropbox, though; the same would be true of any NAS solution, locally-hosted or not.
If you can detect that two files encrypted with different secure keys are the same then you are similarly screwed.
That doesn't require that a server know the key; it only requires that those parties exchange a shared key in advance. It's no different than, i.e., a PSK WPA network password, or a shared encryption key on a workgroup document.
You could still use a service like Dropbox as a reliable offsite backup, while doing all your crypto locally. Think of it as the "availability" service to complement your local policies that insure integrity and confidentiality.
The problem is that Dropbox can't offer seamless encryption while still having lazy file sharing.
On the user's account you would then store a list with keys for each file. Before this list is stored or updated on the server, it is encrypted on the client-side with the user's password, so that the server cannot retrieve this information.
Of course, the security with such a scheme is somewhat lower than with "traditional" encryption, as you can find out who shares a given file. But the advantage of this is that you are still able to block particular files, if, e.g., required to do so by law.