• United States



BitTorrent reply to Hackito report on BitTorrent Sync’s bad crypto: No cause for concern

Nov 18, 20143 mins
Data and Information SecurityMicrosoftSecurity

BitTorrent replied to the unfavorable Hackito report claiming BitTorrent Sync should not be trusted for sensitive data. The response referenced a favorable security assessment by iSEC Partners.

I received a response to the Hackito report from BitTorrent Inc. PR Manager Kevin Fu. BitTorrent referenced an assessment by iSEC “to identify cryptographic security issues.” Below is the main portion of the letter from Nick Rowe, Chief Operating Officer of iSEC Partners. In short, iSEC determined “BitTorrent Sync applied generally accepted cryptographic practices in the design and implementation of Sync 1.4.”

BitTorrent’s emailed response in full:

BitTorrent Sync remains the most secure and private way to to move data between two or more devices; and for good reason – we’ve built it that way. Rigorous third-party security audits have been conducted to verify the product’s security architecture, validated by the attached report.

But we take questions about Sync’s security very seriously. We’ve gone through the claims made by Hackito and after reviewing it in full, we do not feel there is any cause for concern.

To address the main points made in the study’s conclusion:

  • Folder hashes are not the folder key (secret) and are used to discover other peers with the same folder. The hashes cannot be used to obtain access to the folder; it is just a way to discover the IP addresses of devices with the same folder. Hashes also cannot be guessed; it is a 160 bit number, which means that it is cryptographically impossible to guess the hash of a specific folder.
  • Links make use of standard public key cryptography to enable direct and secure key exchange between peers. The link does not contain any folder encryption keys; it only contains the public keys of the machines involved in the exchange. The link itself cannot be used for decrypting the communication. After a direct connection is established (the user can verify that by comparing the certificate fingerprint for both peers) Sync will pass the folder key over an encrypted channel for the other peer. In addition, the public key and the folder hash appear after the # sign in the URL, which means that all modern browsers won’t even send this to the server. On top of that, a few additional features were implemented to further secure the key exchange using links, including (1) the links automatically expire within 3 days (set as default) and (2) explicit approval is required by the inviting peer before any key exchange takes place (also set as a default).
  • We host a tracker server for peer discovery; the tracker is only there to enable peers to find each other. It is not a part of the folder exchange. As mentioned earlier, the hashes cannot be used to obtain access to a folder.
  • Like with any other solution, the user needs to secure access to their machines using proper passwords, proper firewall configuration, and the like. Once an attacker has root access or physical access to the machine, it can modify any element of the attacked system. This is not an issue with Sync, but basic security protocol.
  • Sync security is completely dependent on client-side implementation. The public infrastructure is there to enable better connectivity and more user-friendly folder sharing experience. Compromising the public infrastructure cannot impact the security of Sync.
ms smith

Ms. Smith (not her real name) is a freelance writer and programmer with a special and somewhat personal interest in IT privacy and security issues. She focuses on the unique challenges of maintaining privacy and security, both for individuals and enterprises. She has worked as a journalist and has also penned many technical papers and guides covering various technologies. Smith is herself a self-described privacy and security freak.