kos13

We released everything that we are allowed to release in accordance with iSec agreement. BTW, iSec is the company that will do professional security audit of TrueCrypt.

Please continue discussion in this topic http://forum.bittorrent.com/topic/32592-bittorrent-sync-security-is-our-highest-priority/

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. Recently a post on Hackito from a group of tech enthusiasts speculated on possible security implementation for Sync. We’ve gone through the claims made on 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). They 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 itself cannot be used for decrypting the communication as it only contains the public keys of the machines involved in the exchange. 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. Additional features have been 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. - Sync security is completely dependent on client-side implementation. The public infrastructure is there to enable better connectivity and a more user-friendly folder sharing experience. Compromising the public infrastructure cannot impact the security of Sync - Like with any other solution, the user needs to secure access to their machines using proper passwords, proper firewall configuration, and the like. Should an attacker gain root 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. We’ve been talking with the folks who posted on Hackito to clarify these issues. We’re sure they had the best of intentions with this exercise, but as they have stated, their review was not a professional assessment. As always, we welcome and appreciate a responsible discussion on security. K. Lissounov BitTorrent Sync General Manager

While we are working on more detailed answer. Researcher hasn't found anything bad, besides few crashes on random test. What he found is that we officially saying from the day 1 of the Sync. PS. Wording of "Probable leak of all hashes to getsync.com and access for BitTorrent Inc to all shared data." is very close to "I almost hacked microsoft today" PPS. There is nothing even close to "Bittorrent Inc has access to all your "encrypted files"."

Please try 1.4.82. Now Sync links come with #, instead of ?

I apologize for problems. We will fix it soon.

Great idea. Thanks! Edit. I hope we could use it in product, right?

Developer is here. This was done intentionally, so anyone could verify the data that is sent to tracker server. The data contains absolutely no private information or the way to get access to private data and you could easily verify that. All data that has private data is encrypted on client side and you could verify that by looking to traffic that goes thru relay server. Attacker could only make establishing new connections harder or impossible. Beauty of Sync is that it is fully distributed and true p2p solution, so if we will see these attacks you can do few simple things (DHT, predefined peers) and your instance of Sync will continue working. We are aware of this type of attack and it won't work against of Sync. I understand that these are just my words and it worth nothing when we talk about security. We will have more official info about this soon. This info will work better than my words kos

You can signup as a closed alpha tester, http://blog.bittorrent.com/2014/06/23/help-us-build-sync-a-call-for-alpha-testers/ kos

Current API is not suitable for mobile.

We might find the issue and hope to resolve it in new builds. We suspect that the issue is that access to tracker servers is blocked in some way. We will optimize it, but using predefined hosts might be an immediate help for now.

API key is verified inside a client, so client decides if the key is valid or not. We use the server to check if the particular key is in black list or not. If we see that particular key abuses something, then we contact developer to resolve the issue. If, for some reason, it won't help, then we put the key to black list. I would like to elaborate further, if you don't mind. In p2p world we don't have users, accounts and this is completely new. However we want to make sure that Sync is used for good and developers understand that. True p2p world is completely different from any server based solution, we have to find a right answer on how Sync API should work. And this will change internet and make it truly free. We are here to find a right solution with your help.

I think this is a best solution for now. Not everything is set in stone and we are listening to our users.

Key is needed to block abusive clients. So if there will be a product based on Sync that abuse our API policy, we need to control that.

If the multicast is disabled inside the network, or you have two subnetworks that can't send broadcasts between them - then Sync will be able to find each other thru tracker only.

I am not sure I fully understand you. You could create and link folder, whatever you will put to this folder will be synchronized across devices. So it might be configuration, data, statuses - it doesn't matter. Could you elaborate on what is missing?

It is checked if computer is online.

This is very interesting use case and a short answer - you are right, there will be issues in using API key in this way. And seems you are right that API key needs to be embedded in binary in some way. However then we will face issue with having different binaries for each developer. That means update of binaries will be hard and messy. We are going to work on this and will come up with some solution.

We are going to check this tomorrow, and I will get back to you. In the meantime, could you help us? Please follow these steps http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/ and refer to this thread in problem explanation. This will help us drmatically.

API is self contained - so it will work offline. When distributing the app you have one key per app and generate login/password for each users. Please make sure to make it unique.

I don't want to give a vague answer like - we are working on this, instead I'll elaborate on this topic. 1. Having P2P without dedicated server is really complex. If something bad happens on one device it might be propagated across devices; 2. .SyncArchive means you will never loose any data. It might be not convenient, but it definitely not a "lost forever" 3. We will work with trumad to get all possible information and figure out the issue 4. Surprisingly, there are a lot of cases when people blame Sync, but root cause was something different. Anyway we will find it out. 5. If you, by any chance, can supply us with logs it will help us tremendously. kos

Let's create a list of recommended cloud providers. PM with the details and I will add them to the original post.

In this topic we will list all companies that offers you a cloud part for BitTorrent Sync. You could freely choose solution that is better for you in terms of pricing and features. If you will have any URL you want to mention, send me a PM. Important 1. These solutions are not affiliated with BitTorrent, they just provide you a hosted Sync in the cloud; 2. Since Sync doesn't have backup secret yet, company might have access to your data. - BtCloudSync https://www.btcloudsync.com/ - Incloudibly http://incloudibly.com/en/syncservers

The problem with alignment happens only on old ARM CPU types. The echo 2 command, force CPU to overcome alignment errors by means of emulation, so there will be significant performance degradation for the NAS. Yes it will be fixed, but I can't give you a timeframe for the fix.

I'll check this with developers.