[RubyPinch]

as long as the torrent client knows how to reverse the changes it made to the file (why wouldn't it?) then there won't be any problem.

Its just a really really simple form of "encryption", which most torrent clients do support

[heartsucker]

And then DropBox runs that on every file, so you you have the normal md5 and the torrent-obfuscation-reversed md5. They check both. We have now achieved nothing.

[Morgawr]

What about having a client-side only "corruption" function that is unique for each client? The file is visually the same, the md5 hash is different but when the torrent client is sending the data it just "uncorrupts" the file. When the file is received by another client, that one person's client will take care of uniquely corrupting their own version for storage.

[niij]

This is not possible. The torrent protocol works by checking the hash of each file that it downloads so it can reseed the file. If these files were changed by even 1 bit then they couldn't be reseeded back into the torrent network.

[RubyPinch]

unless the "corruption" is reversible by the torrent client, which it would be

[corobo]

If the corruption is reversible then the people doing the checking can also reverse it. They'll have both the corrupt version and the reverse-fixed version and just have to check an extra hash per thing they're scanning for

[mvanvoorden]

I think that parent means that between torrent clients, the original file is being transferred, but the version that is saved on the hard drive (or Dropbox) is slightly altered, for example by adding/changing a random number of bytes.

When the file is opened in a torrent client, it will recognize these changes, revert them (in memory) and seed the original file.

[reitanqild]

I guess as long as Public Key Encryption works, something like this should be theoretically possible?

[palunon]

If the corruption is based on a value, different for each client (eg, a random number or the serial number of your motherboard), how do you reverse it ?

[pmlnr]

Private key for each client which would salt the file when saved and removed when shared. Could be done, but requires computing and breaks when the client is reinstalled.

[VLM]

Hashes, even md5, are pretty good about going nuts when even one bit is changed in the input. And video codecs (speaking very broadly) are tolerant of a bit error rate like 1e-9 or they'd be useless over the air or on optical media. So simply have your torrent client randomly flip 1 in a billion bits as it downloads. The md5 will never match and the movie quality will be unimpaired.

[corobo]

so if a billion people were to download it, lucky number one-billion would receive a completely garbage file.

Ok, ok. That's not statistically likely to happen. But you do have the problem then of other files being shared via bittorrent, it's not all movie files. You'd also have to re-start basically the entire BT network too, as all clients would no longer be backwards compatible - Good luck too getting every single torrent client dev to implement this at the same time!

[VLM]

Ah the incorrect assumption is that what the filesystem and dropbox scanners see must equal what the torrent client talks about, which isn't actually true.

A preselected and stored in a dotfile or windows equivalent 9 digit number, or the bottom nine decimal digits of a MAC address, or some chunk of a UUID, or whatever. You could salt which bit is gonna get flipped by adding in the filename, or the partial timestamp of the first time the torrent client was ever executed, or one way or another your specific client has a secret nine digit decimal number that it only uses for file operations involving .mp4 extension files longer than a gig (or whatever seems appropriate).

One way or another when you copy a buffer from the torrent system to the filesystem you flip every X-th bit where X is stored locally. Make sure to flip it BOTH when downloading and again when uploading. Your video player won't care when it impacts a single bit error, the other torrent users won't ever know because they never see a flipped bit. Well, technically other torrent users see a flipped, flipped bit, aka the original, unless you're using trinary or something (LOL)

Maybe a mental model is imagining it as the worlds most incompetent FUSE/loop encrypted file system such that the "encrypted" contents on the hard drive have only 1 bit in 1e9 bits flipped and otherwise the remaining billion bits are identical to the "unencrypted" file. Only for "long" .mp4 files, perhaps.

The main problem that would develop is people downloading a torrent, then trying to seed using a machine that has a different "secret bit" above. It would look like your seeder has a tiny bit of file system corruption, which I guess does happen today and is apparently survivable. I would guess most people most of the time do not download a torrent on one system them upload a new torrent on another machine.

There need be no coordination with torrent client devs. Someone could implement this today without anyone else knowing, or it could be done using a FUSE loop filesystem without changing the torrent client at all. I suppose if you never seed a file after copying it to dropbox it would be easy to write a "special cp" that inserts bit error rates around 1e-9 rather than making a perfect copy.

I have no idea based on security posture if you want to slightly obscure every file or just some. Also no need to flip a completely random bit, a smart enough parser could pick the next bit that won't utterly trash the container spec for avi or mkv or ogg or mp3 or pdf or jpeg. So I'm saying flip the next bit that isn't a major file format protocol bit to make it user transparent.

Another weird mental model is think of it like steganography but to defeat 3rd party hash scanners not to hide real data. In fact its hiding not much.

[corobo]

All that sounds a lot of effort when the reality would be they'd just check the file in a different way than full-file md5 hashes as soon as this appeared.

[heartsucker]

Seriously, the easier way to do this is just make a password protected zip file. Boom. Done. No extra mucking around with random bytes and whatnot. You want to share? Give the password to your friends.

[VLM]

Perfect being the enemy of good enough, etc.

Also its a bit unfair. Given this attack, design a perfect defense. OK here's an easy one. Oh OK well that works, but they'll just try a different attack. Well yeah, but that wasn't the initial challenge provided.

Also precomputed rainbow tables aren't so funny when you have gig wide columns instead of hash wide columns. For that alone its an entertaining idea.

[jamespo]

except each client could have its own seed

[wallmani]

If it's reversible like that it is still possible for PayPal and others to implement it too.

[RubyPinch]

Its encryption, you apply a transform before putting it onto the dropbox, and then you apply a transform after you pull it back, and the key it'd be encrypted against would be per user (like most encryption)