handle

Public key cryptography does not solve anything when the private key is also stored on the same machine. Alternatively, if each keypair is different per peer, then you can manually verify each peer that connects to your node, however this is terrible in terms of usability. It means for every one peer you add, due to the distributed nature you have to verify that peer on every single other node. When you add another peer, you have to do that again, with one more to verify, etc. Imagine having to do with when you have 200 or more peers syncing with each other.

This is probably one of the most parroted things I've heard in recent history. Just because something is free does not mean you are the product. It indeed sucks that this is not released as open source, but that's most likely because this is built off a uTorrent codebase, which likely has proprietary portions they are not allowed to release. I'm not discounting the possibility that you may be the product in this case, however jumping to it immediately without considering anything else is plain conspiracy talk.

There is already a solution to this: one-time keys. You send a one-time key over unencrypted email, and provided you set up your copy of bittorrent sync with that one-time key before someone else does, the problem is solved. If someone reads your email afterwards and sees a one-time key, if they use it they will get nowhere because it has already been used. SSL Strip does not work here because not only is SSL not being used, but no keys are being shared and so MITM is impossible and useless unless the attacker already has the key.

Bittorrent Sync is fully peer to peer, meaning there's no centralized web interface that allows you to view your pictures from it. It is a program that runs on your computer directly, allowing you to sync directories with other people who have bittorrent sync. The web gui you are looking at is only available in the linux versions, and is only used for configuration. You cannot view pictures there either. If you want to share your pictures with other people, you will have to set up your own server most likely, however if you set up Bittorrent Sync and install a program called ownCloud, you will be able to share pictures with other people over a web interface. I won't be of any help for you setting up ownCloud, but Google is a good resource.

There are several things that can be said about this idea in general. First, many people are thinking of "email and password" as in signing up to a centralized place and logging in there. This is a terrible idea because it allows that centralized place to access your data at any point in time. There are methods of utilizing a username and password in a decentralized fashion, however, that is secure. An example of such a protocol is SRP, or secure remote password protocol, which allows not only a server to authenticate a client via password, but the client can also authenticate the server with the same password. That being said, this is probably more trouble than it's worth, and a shared secret is perfectly fine to use in a distributed system. The complaint about plaintext keys on disk is a valid one, however it is impossible to hide it from people unless you encrypt it. To encrypt it properly, you need a key that is also not on disk, i.e. you'd have to enter it in every time you start Bittorrent Sync. Once that's done, the key can still be found in the program's memory, and this is absolutely impossible to change, since having the key in memory is needed for bittorrent sync to work at all.

Thank you for your response, glad to hear a cipher mode is indeed implemented over it, and a secure one at that. As for the 128-bit AES versus the documented 256-bit AES, is there any explanation for that? Also, could you explain to me how read-only mode works from a low-level point of view? Thanks

Okay, so under really really specific circumstances (an attacker has two keys that are mathematically related and they know the plaintext behind both of them) AES256 might be less secure, and is still not breakable in a reasonable amount of time. In absolutely EVERY other case, AES256 is leaps and bounds ahead of AES128 in terms of security. Also the "you always have to think that all requirements are fulfilled" quip only goes so far - it really does not apply for this. Next, how does this make them "truthful about security"? It doesn't matter the security of 128 bits or 256 bits, the fact of the matter is that their code uses 128-bit when their marketing and forums say they use 256-bit. That is not being "truthful about security". It is an outright lie. As for you not believing they have implemented that, welcome to the real world. People do dumb things all the time, especially with cryptography. I have no trouble believing it is possible they're using ECB over the wire. I also have a good amount of proof in my screenshot showing they do indeed use 128-bit AES with ECB. If you don't believe that, well, BTLive.exe is publicly available - it's easy enough to perform the same steps to get to that point. CryptImportKey only appears to be called once in the entire codebase.

<Deleted> Disregard my earlier comment.

If that axiom held true, the entire internet would be broken. It does not apply here.

Another thing about cryptography is that it doesn't make things impossible. Instead, it makes things so unlikely/difficult that it might as well not be possible. However small of a chance you think it is, it's smaller than that. And smaller than even that, etc. The chances of winning a lottery is something like 1 in 100,000,000. That's quite a lot, and considering many people put a ticket into the lottery weekly and still win nothing ever in their lives, that's quite a small chance. Now, this system. The total possible number of keys with 21 bytes is a lot. Compensating for the birthday paradox, we would need to divide this number by two to find out the chances of finding a collision. The chances of finding a collision is 1 in 187,072,209,578,355,573,530,071,658,587,684,226,515,959,365,500,928. And that's AFTER being divided by two. If this were a lottery, you could put in a ticket once every microsecond, dare every nanosecond, and still win nothing if you played for centuries. Not only this, but this is just the default 21 bytes. If you create a longer random key, that number increases exponentially per character you add, provided it's completely random.

The chances of that happening are so slim that they are basically none. If every atom on the earth had its own secret, it would still be highly unlikely for any of them to have a collision, let alone for humans of which there are significantly less, and even less when you consider how many humans use the internet, and even less when you consider how many people use bittorrent sync.

Hello, All over the marketing and the forums, it is stated that Bittorrent Sync uses 256-bit AES encryption, and also nowhere is the cipher mode actually stated. I have information that shows me that Bittorrent Sync is instead, actually (potentially) using 128-bit AES encryption. Whilst this may not be insecure, it shows (provided there isn't something beyond the story) that the Sync team is either not being truthful about the security, or there is a disconnect. The other problem (again, provided there isn't something else beyond the story) is that the cipher mode is ECB, or Electronic Code Book. It means there is no mode at all, which is definitively the least secure method of using AES. Is ECB what is used over the wire, or is a cipher mode implemented over this ECB? I have attached a screenshot (also available at https://i.minus.com/i4FurGjh8WjUW.png ) that shows why I believe this is the case. Notice the lines "pbData.aiKeyAlg = CALG_AES_128" near the middle, and "v13 = CRYPT_MODE_ECB" about 1/5 of the way from the bottom. Also while I'm here, can a developer explain how read-only keys work, and how 1) malicious nodes are prevented from syncing in new or modified files, as well as 2) how a read-only node knows the difference between another read-only node and a regular node? Please give the low-level gritty explanation, as I would prefer that over a higher-level one. Thanks