5 ms·
The proof is indeed in the deduplication. If Dropbox can skip the upload process of some large file because another user has already uploaded it, they must also
by bgentry 16y ago
The proof is indeed in the deduplication. If Dropbox can skip the upload process of some large file because another user has already uploaded it, they must also be able to decrypt that file in order to sync it with your other machines.
Or in order for you to download it through the web interface unencrypted.
- rlpb 16y ago> If Dropbox can skip the upload process of some large file because another user has already uploaded it, they must also be able to decrypt that file in order to sync it with your other machines. Not necessarily. The client could send an encrypted version with only (plaintext) hashes of the pieces. EDIT: no, I'm wrong. > Or in order for you to download it through the web interface unencrypted. This one I will give you, unless they're doing something really weird like client side decryption through Javascript, which I'm not sure is even possible. However, they could in theory not store the key until you actually use the web interface (and you don't have to, so they wouldn't have it), and also not store the key when you do.
- shasta 16y agoI suspect that dropbox works the way you think it does, but your argument actually has a flaw. It could work like this: - A hash computed locally (on the clients with the large unencrypted file) and sent along to be used by dropbox to detect dupes. - The key used to encrypt the large file is some function of the file, but not of the hash. The important point is that it's not encrypted with a client specific key, but rather a file specific one. Thus if you have the file, you can compute it. - When a dupe is detected, the server requests that the uploading client send it a copy of the key, encrypted PGP so that only the other intended clients can decrypt it I think that should work.
- bgentry 16y agoInteresting idea.. if one were to build the system as you described, there would still need to be a common link for the PGP encryption of the file-specific key. What do you reckon this is? IIRC, based on the other Dropbox article this week, the only relevant information stored in local Dropbox preferences is your account ID and a unique API token for the specific machine. There was no mention of a plain-text password being stored locally.
- shasta 16y agoWell, dropbox allows you to access all of your data with only a password, so the PGP pair would have to be a function of the password. I'm not sure I follow about storing the password locally. One additional thing that you'd need to do that I didn't mention is keep the file encryption key PGP encrypted on the server. That way, if you know the password, you can authorize access to the file to someone else without having to transfer the file back to whatever machine you're on.
- yoden 16y ago> - The key used to encrypt the large file is some function of the file, but not of the hash. The important point is that it's not encrypted with a client specific key, but rather a file specific one. Thus if you have the file, you can compute it. That's actually an extremely interesting idea. I wonder if using some function of the data, f, to determine encryption keys, leaks information about the encrypted data? My armchair guess would be yes. Of course, the leaked amount (well, the slight-non random distribution by the key being a function of the data) might be small for large files/good function f, which would mean it's probably okay? I've never heard of any research of a cryptosystem that works like that though, so I'd appreciate if anyone could provide some expert input (or maybe we should just email bruce schneier)
- shasta 16y agoI don't see why it would need to leak much more information than you're already leaking with a hash. And I'm sure someone has investigated this idea.