mrf
-
Posts
5 -
Joined
-
Last visited
Posts posted by mrf
-
-
Correct me if I'm wrong, but, you can specify your own value > 32 characters?
Yes, as I said:
I know that the length of the key is variable and thereby can be changed by the user, which everyone should be doing right now, but that's not enough for the ones using the generated secrets. -
@verloren: Your calculation is for a directed attack on one key. We are talking about undirected attacks here. You are forgetting that with every added shared folder the chances are doubled. --> The more folders are shared the easier it becomes to guess a random key. With no secondary security in place BitTorrent Sync will just become less secure with more users and more folders shared.
-
The recommended minimum RSA public_key length is going up from 1024 to 2048 after 31st December 2013[1]. Also RSA is an asymmetric system. Yours is symmetric afaik.
This indicates that your 32 char length is not secure in any way.[2]
[1]See here: http://news.netcraft.com/archives/2012/09/10/minimum-rsa-public-key-lengths-guidelines-or-rules.html
[2]More to read: http://en.wikipedia.org/wiki/Key_size#Symmetric_algorithm_key_lengths
-
I have major problems with the security in BitTorrent Sync:
Currently a "secret" that is generated by the sync app is a 32 character Base64 phrase.
Now, targeted attacks might be very hard or near impossible without the attacker having more information, but untargeted attacks by just guessing ramdom keys en masse are very possible and likely.
Example:Machine A: A folder with the name "my_synced_files" is shared with a "ramdom" Base64 secret. The users tells the owner of machine B about this.
Machine B: A folder with the name "new folder" is created and the same key is saved for it. --> It works!
Machine C (the evil haxor): Tries to brute force the random secrets. He knows that 32 chars in Base64 is having a good chance. So he automates (for example with: Linux, Python, Selenium, the web UI) the creation of the phrase and tries them out on a folder until something works. I works in time!
Also likely are accidental key collisions, depending on how many users share how many folders. The more folders are shared the higher the chance of 2 equal keys generated by different users.
I know that the length of the key is variable and thereby can be changed by the user, which everyone should be doing right now, but that's not enough for the ones using the generated secrets.
A simple and effective way to make these random attacks much harder would be to enforce the name of the shared folder to be the same on all machines in combination with the secret.
Example:Machine A: A folder with the name "my_synced_files" is shared with a "ramdom" Base64 secret. The users tells the owner of machine B about this.
Machine B: A folder with the name "my_synced_files" is created and the same key is saved for it. --> It works!
Machine C (the evil haxor): Tries to brute force the names of the folders and the secrets, but is unsuccessful for a long time, because now it's much harder.
The changes for the Bittorrent Sync API would be minimal as only the Sha2(foldername) would have to be added everywhere.
Currently: SHA2(Secret):ip:port
Possibly: SHA2(Secret):SHA2(foldername):ip:portWhat do you think?
PS: I mean the folder basename not its path. So /home/user/Syncme/my_shared_folder should become my_shared_folder for use in this case.
Security
in Sync General Discussion
Posted
Yes, I sure changed my secrets length. And yes, the folders with the same names would be the idea.
The transport is AES encrypted, not the secret though it's a 32 bit Base64 phrase, which is nowhere near as secure as AES. Aren't you a team member? You should know this.