[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.