Theoretical Insecurity of Bittorrent Sync

Bittorrent Sync (BTSync) is a new product created by Bittorrent company (whom also brought us the Bittorrent technology) for syncing your data between multiple endpoints or parties while leveraging the Bittorrent network and technology.

The product is a closed source product so all I can analyse is via the published details on their website.

I have not found time to sit down and try out the software and would not entrust my personal files to a closed source product to distribute them across the Internet for syncing therefore I may not have the most accurate picture of it's underlying protocol.

The BTSync technology claims to be "very secure" and here are the theoretical weaknesses that increases my discomfort and unwillingness to try it.

According to the Technology page of the BTSync product (bittorrent.com/sync/technology)...

1. Uses Crypto API for Windows. - Please use a better cryptographic library that people have trust in like the Mozilla NSS and OpenSSL suite.
2. According to the technology described for Peer Discovery, BTSync sends out SHA1(Secret):IP:Port to solicit response. It is as good as tell the world that your IP address and Port is open for a specific protocol without people needing to probe your network at all. Sending out a SHA-1 hashed Secret is the greatest danger in this PEX protocol. It is as good as handing out an obfuscated secret key to the world and if someone copies it, they could match it against a rainbow hash table and compromise your security. The better way to do a secret key negotiation and authentication protocol is to secure randomly generate a one-time secure random and use your secret to encrypt the one-time random and distribute it via a key exchange protocol.
3. Sync Trackers and Torrent Servers are a good way of caching your communications and key exchanges. It is as good as giving your adversaries a public cache of your activities. If you want serious security, you should leave as little traces as possible. Metadata are obviously one of the best traces as you can create an activity record more easily.

 Now we have seen the theoretical major weaknesses of Bittorrent Sync, let's try to fix it.

1. For the cryptographic APIs, use NSS and OpenSSL. These are highly recognized and open source libraries. For randoms on Unix systems, use the urandom.
2. The PEX protocol requires an overhaul to include a much more Shared Secret Exchange Protocol I shall describe here (SHASEX). For this SHASEX protocol, it shall remain in the public, unlicensed and unpatented forever and I genuinely am unaware of any such patents or inventions/creations when I write this SHASEX protocol version 1 here.

   1.     We shall assume that all clients have the same shared secret key loaded (K).

   
   

   2.     The party that requests communication to all clients generates a random (R) and uses the secret key shared amongst them (K) to encrypt R. Thus, EK(R) and sends it to everyone known.

   
   

   3.     Since everyone has the same shared secret, everyone decrypts the random which is no used as a shared negotiation key so that every client can establish their unique session keys. All clients would randomly generate their own session key independently with the requestor. Let U be the unqiue random each client generates at random for their own session keys. Now all clients would use the R random to encrypt their U random thus. ER(U) and sends it to the requestor.

   
   

   4.     The requestor would consolidate all the client's session key, U, and communicate to them using their own session keys (no sharing of session keys for privacy).

   
   

   5.      By this method, when an attacker from the outside looks at this protocol, all he sees are encrypted values moving around, not plain hashed keys. When the attacker views the session keys, they will have values that are not the same due to the usage of different session keys. Thus, if an attacker were to collect all the encrypted session keys, he would need to break a variety of keys in order to get to the same data and the same data, due to being encrypted with different session keys that are securely generated, would also appear different thus making cryptanalysis even harder.

   
   

   6.     The weakness of this SHASEX protocol to my knowledge and is an unintended consequence of such distributed, decentralized and lightweight design would be to compromise one of the clients hosting the same shared secret keys, intercept all their keys and do a man-in-the-middle.... that if ... the attacker manages to know the secret key by compromising any of the clients. To prevent the stagnation of secret keys, it is best to discard and regenerate shared secrets everytime a session has been ended. The requestor would have to generate a random shared secret and encrypt them with the session keys, distribute the secrets, before closing the connection.

   
   
3. To try to lessen footprints on servers and trackers, try to use less of them.

These are all the comments and recommendations I have now for the improvement of the BTSync protocol.