Security

[mrf]

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:port

What 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.

[verloren]

You might be surprised at how unlikely the brute force method is. The combination of 32 characters, each of which could be one of 32 values, gives 32^32 possible options, which is a very large number (almost 1.5 quindecillion, a number so big my spell checker doesn't recognize it!) In practical terms, let's assume that a potential thief decided to guess your secret. Being a forward-thinking chap, he got started as soon as the universe was created. He realized he can't do this alone, so he recruited every human who has ever existed up to now (~50 billion). He gave each of them 3.5 billion computers, each one of which can guess and test a billion secrets per second. Very roughly, as I type this he'd have a 50/50 chance of having guessed your secret.

[kos13]

As verloren properly explained, the possibility of someone hit your Secret is close to 0. All current security is based on probability, for example you could guess RSA private key and break whole internet. Probability of guessing RSA private key and Sync secret is very close.

[mrf]

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

[mrf]

@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.

[Automatic Coding]

Correct me if I'm wrong, but, you can specify your own value > 32 characters?

[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.

[Automatic Coding]

Yes, as I said:

Oh, I completely missed that, sorry. Well, one way of doing it would just be to change the length from 32 to 128 or larger (In the generation code, which, apparently I can't find in the javascript. I gave up after ~ a minute), another way is to just say "Security isn't automated, do it yourself" and let users do it themselves.

I know I changed my secret, and, I'm sure you did to. I understand not everyone will, but, that's kind of their fault. I do agree though, however, I dislike having to have the same folder names (As I believe that's what you're saying?)

[kos13]

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...s-or-rules.html

[2]More to read: http://en.wikipedia....thm_key_lengths

Sync use AES encryption.

[verloren]

@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.

You're right, it does become less secure. But that changes the math as well. Now we're not facing somebody trying to attack us, we're just hoping we won't get a clash. It's possible that the first two secrets randomly generated could have matched, and the more secrets generated the more likely a clash is. But the universe of possible values is so large, and the rate of generating secrets is so very small, that it's still a near-zero risk.

We could combine these two, and have a hacker who is trying to brute-force *any* shared secret. Again, we have 32^32 possible secrets, but let's assume that every person on the planet is sharing a folder with everyone else - now we have 7 billion^2 possible secrets to guess. So the chances of guessing any of those secrets is about 4.9*10^19 / (32^32). Let's call that odds of a squillion to one. To be 'reasonably sure' of getting a match, then, I need to try a squillion secrets. If I tried a billion secrets on each of a billion computers it would take over 940 years to do this.

None of that changes the fact that you could still experience a clash. I'd like to see some notification from the client every time a node uses your secret for the first time (the information is already available in the gui, it just doesn't draw your attention to it at the moment), so you can check whether that's you, a friend, or a random clash. But statistically speaking that's entirely to reassure me, rather than to combat a likely danger.

[mrf]

Oh, I completely missed that, sorry. Well, one way of doing it would just be to change the length from 32 to 128 or larger (In the generation code, which, apparently I can't find in the javascript. I gave up after ~ a minute), another way is to just say "Security isn't automated, do it yourself" and let users do it themselves.

I know I changed my secret, and, I'm sure you did to. I understand not everyone will, but, that's kind of their fault. I do agree though, however, I dislike having to have the same folder names (As I believe that's what you're saying?)

Yes, I sure changed my secrets length. And yes, the folders with the same names would be the idea.

Sync use AES encryption.

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.

[Automatic Coding]

Yes, I sure changed my secrets length. And yes, the folders with the same names would be the idea.

Yeah, I just don't like that. Say I share a folder with my mate, Bob, I may call it:-

"Shared with Bob"

However, Bob isn't sharing with himself, so, he may call it:-

"Shared with Nick"

In which case, both of our syncs would be marked invalid. I honestly don't like this idea.

[GreatMarko]

Yeah, I just don't like that. Say I share a folder with my mate, Bob, I may call it:-

"Shared with Bob"

However, Bob isn't sharing with himself, so, he may call it:-

"Shared with Nick"

In which case, both of our syncs would be marked invalid. I honestly don't like this idea.

I'm not sure I follow? Folder's don't have to have the same name on each device for you to sync them!

If you have a folder named "Shared with Bob" on Device A, you can sync this with a folder named "Shared with Nick" on Device B! BitTorrent Sync doesn't care what the folder's are named - the association between folders is based on the same secret, not the same folder name!

[Automatic Coding]

I'm not sure I follow? Folder's don't have to have the same name on each device for you to sync them!

If you have a folder named "Shared with Bob" on Device A, you can sync this with a folder named "Shared with Nick" on Device B! BitTorrent Sync doesn't care what the folder's are named - the association between folders is based on the same secret, not the same folder name!

But (From my understanding) OP wants to make it so that folder names are another form of security, they're currently not, which is how I like them.

[GreatMarko]

But (From my understanding) OP wants to make it so that folder names are another form of security, they're currently not, which is how I like them.

Ah, right - got ya!

In which case, I agree with you - it's often useful to have different folders named differently on different devices. Forcing sync'd folders to all have identical names in order for them to sync wouldn't be all that great, and wouldn't go down well with existing users (who would be used to syncing any folder to any other folder and then suddenly wouldn't be able to!)

There are plenty of alternatives to potential further enhance security - I personally wouldn't want to be forced to use the same folder name on all devices!

[Evgeny]

Explain me please few things:

Does Bit Torrent Server generate Secret for me, or it happens localy?

Does BT Server knows my generated Secret?

Will BT Server know my custom generated Secret?

I ask it becouse there is such information about Peer Discovery:

"BitTorrent Sync can use a specific tracker server to facilitate peer discovery. The tracker server sees the combination of SHA2(secret):ip:port and helps peers connect directly."

In other words - does BT Server has any posibility to get access to my shared folders?

Thank you!

[GreatMarko]

Does Bit Torrent Server generate Secret for me, or it happens localy?

Locally

Does BT Server knows my generated Secret?

In order to establish connections with your other (non-local) devices, your secret is encrypted/transmitted securely to the tracker

Will BT Server know my custom generated Secret?

See above answer

In other words - does BT Server has any posibility to get access to my shared folders?

Not unless it can decrypt your encrypted key (which basically it can't!) - See the first FAQ entry here

[Evgeny]

Not unless it can decrypt your encrypted key (which basically it can't!) - See the first FAQ entry here

Thank you!

But I still can't understand the last thing - if BT knows my Secret (32 sings key) - why it can't access my shared folders? On your linked webpage I didn't find information about that.

You say that key ("Secret" - right?) transfers to BT encrypted. Then how BT Server can use it to connect my on-line folders for syncing, if it can't see the key itself?

[Urist]

I would imagine because your secret encrypts to the same sha2 that another computer using the same secret encrypts to. The tracker then just links up the two sha2 (which are the same) secrets together. The tracker can't reverse engineer your secret from the sha2 that it uses to link up peers.

I wonder what would happen if the tracker was compromised..

[perennate]

> I wonder what would happen if the tracker was compromised..

What do you mean? Like you said, the tracker only knows the SHA2 of the secret. So nothing would happen if tracker is compromised, you'd just make connections to peers that don't share your secret and then only realize that after making the connection; your IP address is publicized but not the secret itself. SHA2 in this system is designed to be public.

[Urist]

I'm just imagining stealing a mob guy's address book that's written in code. Sure you can't read it yet, but you can try and break his code.

All this crypto is greek to me, so I should probably keep my mouth shut!

[henryk]

@mrf I see your problem, but all your calculations and assumptions are way off.

Assuming the secret has full entropy in any case (http://labs.bittorre...ogy.html#secret mentions using dev/random or cryptoapi for that) we have, for the various mentioned secret lengths:

• 32 characters of base-32 text, meaning 5 bits per character: 160 bit of entropy
  
• 40 characters of base-64 text, meaning 6 bits per character: 240 bit of entropy
  

(@verloren: Thinking of security in terms of "number of possible combinations" usually leads to ununderstandable numbers and in security discussions should be reserved to snake-oil vendors who want to dazzle you with incomprehensibly large numbers with no real meaning. Just express everything in log₂, that is: bits, and everything becomes so much easier. Especially since multiplication becomes simple addition.)

@mrf: The security of AES-128 is about 128 bits. It is generally agreed upon that any number exceeding the ~80-90 bit mark falls into the "impossible" category. There are various nice calculations about the effort needed to break a 128 bit key with results like "storage: 1 result per atom -> more atoms than there are in the universe", "more time than is left before our solar system is swallowed by our sun" and "the energy required would boil up all the oceans on planet earth". I think full-entropy(!) keys of this magnitude can safely be said to not be worth worrying about.

Compare your folder name suggestion: English language has an entropy of about 1-2 bits per character, folder names will probably be about 10 characters average (note: this is the only number I've pulled out of my ass), leaving you with about 15 bits of additional entropy. Compared to the 160 bit we talked about before that's next to nothing. But adds considerable inconvenience (see Automatic Coding's post).

@mrf The other point you were talking about (undirected attacks) is called a birthday attack. Instead of breaking a a particular key, in this instance an attacker just wants to find *any* two identical secrets. For an attack on a specific secret of length 160 bits, an attacker can expect to succeed on average after 2¹⁵⁹ tries. For a birthday attack success will, on average, reach a high probability after approximately 2⁸⁰ attempts (half bit size).

Now: 80 bits is still insanely large. Additionally think about what it means: The collision the attacker would find would with overwhelming probability be one with his own attacks.

More realistically attacking *any* other secret should be treated as subtracting from the secret length. Say every person on earth (7 billion) had a thousand synced folders, leading to 7*10¹² distinct secrets on the network. In log₂ that's about 43. The complexity to attack *any* folder now is 160-43 = 117 bit. Have fun boiling the oceans while waiting for the sun to go red giant! :-)

@kos13/bittorrent sync team: I still have problems understanding the security properties. One of the issues is the exact secret length. The number above (32 characters base-32) I came up with by counting in the screenshots. Your website sometimes mentions 21 bytes, which is different from 160 bits. Also you offer up the encryption algorithm to be AES-256, which whould require a 256 bit key. Then there's the base-64 thing with still a different number.

A concise table with exact security parameters (paying attention to the distinction between bytes, bits and characters) would be nice.

Also, coming from sort of a security background, I don't fully understand how read-only/time-limited keys are supposed to work. It would be really great if you had a protocol description somewhere. How does a secret become a key? How is the actual transmission protected?

--

Henryk Plötz

Grüße aus Berlin

[splat]

Currently a "secret" that is generated by the sync app is a 32 character Base64 phrase.

You're confusing the encoding with the secret length. It's a random 21 bytes that have been "base32" encoded (there's a lot of base32 alphabets, and I don't know which one was used, hence the quotes). 21 bytes is 168 bits, which is the key strength of Triple DES. Personally, I'd like the default strength to increase to 32 bytes of entropy (256 bits), but that's not to say the current length of 168 bits is anywhere near insufficient.

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.

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:port

What 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.

If we increase the minimum secret size by enough to accomodate a digest of the folder's name, we'd be strictly better off using those same bits for purely random entropy. If you have a 5-character folder name, that's approximately 29.7 bits of entropy presuming a purely random choice (in reality, there will be far less). Contrast that with the 40 bits of entropy using those same 5 bytes to store a (secure pseudo-) random number. Which would you prefer? Remember, this is a log scale, so having 1/3 more bits makes you far more than 1/3 more secure.

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.

The danger with public key cryptography is that it's possible, though infeasible, to reconstruct the private key given the public key. The definition of infeasible is a moving target, however, hence the need to have more bits and up the ante with some regularity. Symmetric keys can be much shorter, and in fact triple-DES uses exactly a 21-byte key (the BT Sync secret length).

... another way is to just say "Security isn't automated, do it yourself" and let users do it themselves.

I disagree entirely with that statement. Security is far better when automated -- could you execute AES256 properly by hand? Moreover, could you come up with a secure cipher by yourself? Even if you could, how many side-channel attacks would it be vulnerable to? Coming up with secure entropy is in the same general ballpark of difficulty, and I have every expectation of myself and others to muck it up (see also: passwords that are children's or pet's names, or common words, or even 'password').

Taking away control from the users does dramatically increase security, but decreases the feeling of it. That's not a small hurdle (largely, I'm asking for the "secret generation" page to train users about probability), but giving users more and more ways to shoot themselves in the foot is solving the wrong problem.

I would imagine because your secret encrypts to the same sha2 that another computer using the same secret encrypts to. The tracker then just links up the two sha2 (which are the same) secrets together. The tracker can't reverse engineer your secret from the sha2 that it uses to link up peers.

I wonder what would happen if the tracker was compromised..

That would be a concern, as sha2 is not designed for secure storage (it's designed to be extremely fast, for message authentication). The attackers who compromised the tracker's state would have a monumental task, but the ridiculous rates at which they can compute sha2 hashes on a GPU makes the game less in our favor. If the tracker used something like bcrypt or a fast digest in a PBKDF2-like mode, that would be far less of a concern.

[splat]

@kos13/bittorrent sync team: I still have problems understanding the security properties. One of the issues is the exact secret length. The number above (32 characters base-32) I came up with by counting in the screenshots. Your website sometimes mentions 21 bytes, which is different from 160 bits. Also you offer up the encryption algorithm to be AES-256, which whould require a 256 bit key. Then there's the base-64 thing with still a different number.

A concise table with exact security parameters (paying attention to the distinction between bytes, bits and characters) would be nice.

Also, coming from sort of a security background, I don't fully understand how read-only/time-limited keys are supposed to work. It would be really great if you had a protocol description somewhere. How does a secret become a key? How is the actual transmission protected?

Fear not, your request has been made before -- there's a detailed publication in the works on the protocol and the various security bits and bobs.

As for the read-only / time-limited keys, what we know is that the generating Sync node stores them and matches incoming requests against its per-folder set of secrets. If it's a time limited secret, the generating node forgets it after 24 hours. If it's a read-only secret, presumably the master node knows to drop writes on the floor.

As for how the transmission is protected, data is AES encrypted (in some mode, with some key presumably derived from the secret somehow), but the authentication handshake is still a mystery. For what it's worth, I can't seem to sniff my key out of my local traffic (caveat emptor: I don't know which base32 alphabet is being used, the one I picked is probably wrong) so it seems to be obfuscated in some way. Whether that obfuscation is cryptographically secure or merely ROT13, I can't comment.

[PeterVerhees]

As henryk pointed out in the next post, I am completely talking sh*t in this post. Please ignore this post and DO NOT FOLLOW any advise in it, apart from using more bytes in your key generation.

I kid you not, I am ashamed of overlooking the facts henryk points out and am bewildered of the fact I wrote this text. It must have been far past my bedtime.

You can take a LOOK at the sites I mention, because they have interesting info about entropy, but do NOT use their data!

Coming up with secure entropy is in the same general ballpark of difficulty, and I have every expectation of myself and others to muck it up (see also: passwords that are children's or pet's names, or common words, or even 'password').

When worried about entropy used in your random key, please take a look at http://random.org or http://www.fourmilab.ch/hotbits/

I use these to generate my own key, not depending on PRNG's.

See my simple, badly written, attached bash script. (it filters out / + for copy paste in mail and uses a 42 byte key, for obvious reasons)

#!/bin/bash

bt_bytes=42
bt_token=""

while [ -z "$bt_token" ];
do
	 bt_token=`wget -qO- "https://do-not-do-this/" | base64 -w 0 | grep -v "/" | grep -v "+"`
done
echo "TRNG Nuclear:	 "$bt_token

bt_token=""
while [ -z "$bt_token" ];
do
	 bt_token=`wget -qO- "https://do-not-do-this" | base64 -w 0 | grep -v "/" | grep -v "+"`
done
echo "TRNG Atmospheric: "$bt_token

bt_token=""
while [ -z "$bt_token" ];
do
	 bt_token=`head -c $bt_bytes /dev/urandom | base64 -w 0 | grep -v "/" | grep -v "+"`
done
echo "PRNG urandom:	 "$bt_token

I am still looking into a way to combine the TRNG outputs with the PRNG output to foil any attack on my key from persons owning the sites and still keeping the true randomness. Keep you posted.....

Edited April 27, 2013 by PeterVerhees