Is There Proof That Bittorrent Cannot Decrypt Files?


Anaqreon

Recommended Posts

There are many discussions about the intrinsic security of Sync encryption, but this topic is not about that. I'm confident that the encryption used is solid. I would like to know if there is proof that there is no "backdoor" in the Sync software that could allow a third party to decrypt files. I have searched repeatedly but have not found any substantive discussion about this obvious question.

 

The only reason this is a worry, of course, is that the Sync client is not open-source. While the decision for it to remain closed is understandable (and not the relevant topic here), it does place the burden of proof on BitTorrent to assure users of their data privacy. Is it even possible to prove this without knowing the code? Perhaps several independent third party security audits would be better than nothing. Have these taken place?

 

I recognize that it is always possible to encrypt files yourself before they are accessed by the Sync client (or even Dropbox or any other file sync provider) in order to neutralize any potential backdoor, but this method is of course not how the system is advertised and adds a layer of complexity most people will not use. Such a discussion would be distracting and off-topic for this specific question about what proof exists for Sync data privacy and/or what the nature of that proof is.

Link to comment
Share on other sites

Bittorrent could easily phone home at any time sending the secret to their server. It would be almost impossible to detect this, assuming they obfuscated it using modern techniques.

 

All we have is trust and the fact it would be a serious criminal offence to lie about the amount of security the product is providing.

 

No doubt one day there will be a working open source implementation. Until then, paranoid users should not install bit torrent sync on any computer that has sensitive data. Encrypting the files yourself is not good enough, bit torrent sync might read the RAM contents of your encryption software and phone home with the password.

 

BitTorrent doesn't have any burden of proof because it is _impossible for them to provide proof_.

Link to comment
Share on other sites

Thanks for your thoughts. I have warm fuzzy feelings about BitTorrent as a company, but if we have learned anything from the revelations about NSA and related agency activity, it is that companies can be coerced into violating the privacy of their customers whether they want to or not, while the legality of the action seems to be an almost irrelevant concern to the government agencies. This makes me sad but it is a hard truth that must be confronted in the absence of institutional reform.

 

Is it possible in Linux for a process running as a normal user to access the memory of any other process run by the same user? If so, perhaps it is best to run Sync as a separate user dedicated only to that application. Would that be safe enough?

 

What used to be paranoid behavior, as you say, now seems to be simply prudent.

Link to comment
Share on other sites

I recognize that it is always possible to encrypt files yourself before they are accessed by the Sync client (or even Dropbox or any other file sync provider) in order to neutralize any potential backdoor

 

That wouldn't solve anything, as you are running it (likely) on the same machine as the data, so if you don't trust the software, you should not run it, as it could do much more behind your backs, running on your system.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.