9 ms·

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

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      unless the "corruption" is reversible by the torrent client, which it would be
      - corobo 10y ago
        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
        reitanqild 10y ago
        I guess as long as Public Key Encryption works, something like this should be theoretically possible?
        niij 10y ago
        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 10y ago
        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 10y ago
        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 10y ago
        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
      - pmlnr 10y ago
        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.
- jamespo 10y ago
  except each client could have its own seed
- VLM 10y ago
  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 10y ago
    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 10y ago
      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.
wallmani 10y ago
If it's reversible like that it is still possible for PayPal and others to implement it too.
- RubyPinch 10y ago
  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)

heartsucker 10y ago

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 10y ago
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 10y ago
  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 10y ago
    unless the "corruption" is reversible by the torrent client, which it would be
    - corobo 10y ago
      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
      - reitanqild 10y ago
        I guess as long as Public Key Encryption works, something like this should be theoretically possible?
        niij 10y ago
        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 10y ago
        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 10y ago
        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 10y ago
        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
    - pmlnr 10y ago
      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.
jamespo 10y ago
except each client could have its own seed
VLM 10y ago
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 10y ago
  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 10y ago
    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.

wallmani 10y ago

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

RubyPinch 10y ago
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)