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

[niij]

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.

[figgis]

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?

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

[corobo]

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

[EdHominem]

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.

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