4 ms·

"...but it means that files can't be securely encrypted" I'm sorry, but I don't follow. For all bit-identical copies of a file, the secure hash will be the sa

by rcoder 16y ago

"...but it means that files can't be securely encrypted" 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.

oiuytgyuio 16y ago
If two files uploaded by different users used the same key (ie the server stores the key) then you have no security anyway. If you can detect that two files encrypted with different secure keys are the same then you are similarly screwed.
- rcoder 16y ago
  I was really just talking about trusted parties reusing a private key (say, for an encrypted disk image shared amongst team members) not arbitrary strangers on the 'net. 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.
  - oiuytgyuio 16y ago
    Yes, but that's no different from encrypting a file locally using truecrypt/pgp etc and then uploading that. The problem is that Dropbox can't offer seamless encryption while still having lazy file sharing.
- gst 16y ago
  You can use different keys for each file that you derive from the file itself. So if two user's store the same file they encrypt to the same data, but no one is able to decrypt such data without knowing the file. 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.

by rcoder 16y ago

oiuytgyuio 16y ago

If two files uploaded by different users used the same key (ie the server stores the key) then you have no security anyway. If you can detect that two files encrypted with different secure keys are the same then you are similarly screwed.

rcoder 16y ago
I was really just talking about trusted parties reusing a private key (say, for an encrypted disk image shared amongst team members) not arbitrary strangers on the 'net. 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.
- oiuytgyuio 16y ago
  Yes, but that's no different from encrypting a file locally using truecrypt/pgp etc and then uploading that. The problem is that Dropbox can't offer seamless encryption while still having lazy file sharing.
gst 16y ago
You can use different keys for each file that you derive from the file itself. So if two user's store the same file they encrypt to the same data, but no one is able to decrypt such data without knowing the file. 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.