Live data from Hacker News

Dropship — successor to torrents?

forwardfeed.pl

61–70 of 74 posts

Re: Dropship — successor to torrents?

#61
post #36
post #20

Earlier quoted context omitted.

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 Dr…

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: {"blocks": ["f3f754a5dcd93f271ad013a5ee84f495a36da84f152e0a1fec4646345b0c10d…

Yeah, Canon PowerShot A60 ;)

Re: Dropship — successor to torrents?

#63
post #10

This isn't even remotely similar to bittorrent, it's more akin to rapidshare et al. You're completely at the whim of a 3rd party, Dropbox. And I'm pretty sure something like this would violate whatever contract you agree to when signing up. So no, not a successor to torrents.

I'm pretty sure I've seen stuff suggesting that Dropbox occasionally purges copyrighted files from its system (which is made super-easy by the hash fingerprinting system that it uses to deduplicate storage) so I agree that this is not likely to meet most people's use case for torrents; i.e. stealing copyrighted music and films. I wonder why the github repo has been taken down.

[deleted]

Re: Dropship — successor to torrents?

#65
post #29

forgive what is possibly a very ignorant question, but are there security concerns here? I understand that the key space is immensely huge and that for any file over 4MB in size it would be virtually impossible to guess, but what is to stop someone from just trying hashes for fun to see if they get interesting files? Like I said for file over 4MB it seems fine, guessing sequential hashes would be all but impossible.…

I see your point here. I hope non-public files are protected from Dropbox's deduplication

Re: Dropship — successor to torrents?

#66
post #36
post #20

Earlier quoted context omitted.

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 Dr…

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: {"blocks": ["f3f754a5dcd93f271ad013a5ee84f495a36da84f152e0a1fec4646345b0c10d…

When I run dropship with a file containing the JSON you quoted, it prints, "('Oops, blocks are not known: %s', [u'8_dUpdzZPyca0BOl7oT0laNtqE8VLgof7EZGNFsMENY'])".

Re: Dropship — successor to torrents?

#67
post #65
post #29

forgive what is possibly a very ignorant question, but are there security concerns here? I understand that the key space is immensely huge and that for any file over 4MB in size it would be virtually impossible to guess, but what is to stop someone from just trying hashes for fun to see if they get interesting files? Like I said for file over 4MB it seems fine, guessing sequential hashes would be all but impossible.…

I see your point here. I hope non-public files are protected from Dropbox's deduplication

They aren't. A colleague copied a whole bunch of documentation from his private Dropbox onto my computer; when I then copied it into my Dropbox it took around half a minute to sync and it was a couple hundred MB.

Re: Dropship — successor to torrents?

#68
At last. I'm surprised nobody thought of implementing this earlier. I thought about it, but this being a direct attack on Dropbox, I don't see much value in it. Apart from being unethical, it will only force Dropbox to either remove this very useful feature, or implement a challenge-like system which will render this useless. This will be short-lived code if it spreads.

In fact, I think this "feature" is one of the (many) reasons why Dropbox doesn't have an opensource client. And it isn't exposed it in its so-called "API".

Edit: I just saw that they killed the feature: http://news.ycombinator.com/item?id=2483053

Re: Dropship — successor to torrents?

#70
post #14
post #11

Earlier quoted context omitted.

What would stop pirates from querying each other (maybe on some P2P network) for those random bytes? Client A wants the file that Client B has so when Dropbox asks Client A for some random offset, Client A asks Client B in the background and relays the result to Dropbox. It really depends on how far pirates would be willing to go.

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.

For some reason, this inspired me to write a blog post: http://a3nm.net/blog/deduplication_attacks.html and http://news.ycombinator.com/item?id=2489594

Post reply on HN