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.
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.
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.
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
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.
Can you explain how Public Key Encryption would be related? I was thinking more in terms of a torrent client corrupting a predictable last bit of each saved file (which could cause tons serious corruption issues in itself for non-media files). This appears to only be feasible if each user had their own private key that could be used to compute where the corrupted bit is added to media files.
If you are using a torrent application, it is safe to say that either you or your actual torrent application can connect to the internet and create a key... If you chose to opt out than that is fine, if you choose to opt in you get what was discussed previously.
Not sure why you would go the route of having it predictable?
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 ?
If you can't reverse it you can't seed it anymore and BitTorrent breaks
Even if that's not the case they'd just switch from grabbing a hash of the entire file to finding sub-hashes of the file or other fingerprints. You'd have to do a lot of corrupting to make this worth it.
If adobe premiere can sync my audio tracks when one is barely audible and the other has background noise you better believe there's a service that can find stored movies against a database of files
Also if you're already using BitTorrent why are you sharing these files on Dropbox et al
The idea is to save the file on Dropbox, but wrapped in symmetrical encryption so that they don't know what it is. You know your key because you created it, but they don't.
Your torrent client would see the normal file, they wouldn't see anything except random garbage.
Why? Um, perhaps to have a "torrent box" which stored data in a more accessible place?
Perhaps just to crap on someone's stupid censorship.
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.
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.
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!
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.
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.
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.
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.
