"These utilities make use of the deduplication scheme of Dropbox__
to allow for "teleporting" files into your Dropbox account
given only a list of hashes, provided of course that the files already exist
on their servers. This enables arbitrary, anonymous transfers of files between
Between this and the minor information leakage issue I suspect Dropbox will be making changes to their deduplication scheme.
A simple way to fix both of these issues is to require each user to upload the complete file once, regardless of whether Dropbox already has it stored. Deduplication in storage and per-user uploading is still possible.
Also interesting to note is the Github repo for this has been deleted. Tarball of the source is still available.
Napkin-cryptographic way how Dropbox could fix this while still getting full deduplication: currently, when the client discovers that a file has been added locally, it sends hashes of 4MB blocks, and the server considers the file added.
Additional measure at that point: the server could challenge the client to provide the values of bytes at a couple of arbitrarily chosen byte offsets of the original file. (Could precompute that, provided the queries don't repeat often).
Of course, Dropbox can't prevent people from sharing content out of band. But if Client A and Client B are offering arbitrary byte ranges to complete strangers, they are effectively playing BitTorrent again.
Yes, but they are only exchanging a constant amount of information to fool the server challenge, whereas we could hope to do better if the server builds challenges which use information that he knows the client has.
As far as I understand the original posting, you can download any file from Dropbox's servers if you know its Dropbox hash, which apparently is a sequence of SHA256 hashes of 4MB blocks.
If you have a sub-4MB sensitive file, and you publish its SHA256, and the Dropbox protocol applies the hash function in the same way as file hashing tools (e.g. doesn't include a tag meaning "this hash is computed particularly for Dropbox deduplication" into the SHA computation), yes, then apparently people can download your file.
However, I rarely see SHA256 checksums along with download links; more SHA1 and MD5.
That's still a bit worrying though; do people stop to consider that publishing a SHA256 hash bears the risk of being equivalent of publishing the file itself (assuming someone uploads it to dropbox)?
Another related attack could be to start with a known file (say, your employment contract), swap out the name with a colleague and generate a bunch of files with different salary amounts, essentially bruteforcing sha256 sums. If dropbox suddenly coughs up a file, you've revealed his salary!
Assuming you know the exact structure of the file this would be a perfectly valid attack. There could be a lot of variance in rich formats like PDF files from things like compression, etc, so this might be expensive to perform on non-plaintext files.
Dropbox effectively acts as an "existence oracle". You can't ask it to cough up a file you don't have, but you can ask it if a given file exists anywhere in the system.
This would be an effective way for law enforcement or copyright civil enforcement to check for content that is clearly illegal or a certainly copyright violation to possess. They would need to query for a set of hashes of the given illegal content. If any matches returned positive data, they would be able to issue a subpoena for all users who stored the given content in their dropbox folder and pursue them further.
> for content that is clearly illegal or a certainly copyright violation to possess
How can something be "clearly" a violation? If I have an album, but copy someone else's rip instead of making my own - is that "clearly" a violation? Alternatively if I used the same application, I'd probably obtain the exact same file - is that clearly a violation too?
(grooveshark kind of operates on the assumption that it's ok)
Just read the reappeared sourcecode (assuming it works as advertised): The hash is an SHA256 of pure 4MB blocks in the input file. They add no message type information which could prevent mixups between Dropbox-deduplication hashes and hashes computed for other purposes.
The following dropship file was assembled using only shasum, ls and vi: