A thought it was secure ?

[kos13]

I just leave it here http://www.keylength.com/

[romaimperator]

I'd like to add that if sync used any kind of standard authentication (i.e. usernames/passwords, OTP, OAuth, etc.) that it would require some centralized service to provide the authentication. That would eliminate the distributed feature which is one of the distinguishing benefits of Bit Torrent Sync.

[Heavensrevenge]

Yea I do prefer one string too, and the reason on why I sugested that SHA-3 hash function is because it's authors designed a special MAC mode for it to be used specifically for encrypted authentication. But I'm thinking that the string itself may not be good enough, hard code some magic value into the client's internal data to get a resultant broadcast or something, so we never truly know what the string is AND it'll be like some massive bitstream damn near impossible to crack or guess even though brute-force methods.

https://blogs.rsa.com/keccak-effect/ has a bit of info, but they made a presentation and a paper about using Keccak for encrypted authentication.

[rdebath]

So you're saying that SHA3 gives the opportunity for better performance because the MAC and the encryption are done at the same time.

This might be true if the algorithm is in itself quick enough. The problem I see with that is that there are specific instructions built into current x86 processors that are included only to calculate AES encryption. The OpenSSL library that BTSync uses has assembler routines to encrypt using these instructions if the (run time) processor supports it. This generally makes it a rather quick algorithm in practice even though others might be faster in theory.

Another problem with SHA3 is that OpenSSL doesn't do it yet. So they'd have to change the encryption provider not just 'flick over' to a different algorithm.

From what I've read SHA3 is not a security upgrade there are no indications that SHA2 has any significant security problems. The only reason for switching over is a possible improvement in performance. Now while this has been proven in a "level playing field" most current processors and devices have a substantial bias to AES. If this "bias" (these AES partials) can be reused for SHA3 or SHA3 is good enough without them the switchover can be quick. If not it'll have to wait several years for the hardware assists to become common. In either case a well supported multi-protocol library like OpenSSL is probably the best choice to get there quickest.

BTW: Changing the hash algorithm later is a "clean" change as the same key will provide different "info hashs" depending on the algorithm used. But changing the algorithm results in lots of "encryption failure" errors. So ...

kos13 Can I request that unlike the 1.0.* to 1.1.* transition the generation of the "info hash" depends on the encryption algorithm in use and the protocol version. ... eg: SHA2("BTSync" + Secret + ProtocolVersion.tostring + EncryptionAlgoritm.tostring + EncryptionFlags + ...)

[kos13]

kos13 Can I request that unlike the 1.0.* to 1.1.* transition the generation of the "info hash" depends on the encryption algorithm in use and the protocol version. ... eg: SHA2("BTSync" + Secret + ProtocolVersion.tostring + EncryptionAlgoritm.tostring + EncryptionFlags + ...)

Why this is important to you?

[rdebath]

It's initially back on the tidyness issue, it helps make the application more stable and means that debugging is easier in that if the settings are such that if the two peers won't be able to communicate they can't even see each other. That way I know that if they are trying (and failing) to communicate then it's a network (NAT) problem if they're not even trying it's a setup problem. To illustrate there is a setup issue like this in OpenVPN in that if you use the 'comp-lzo' option on only one side it looks like the ends should be talking to each other; one end will believe the connection is working and the other end doesn't. This looks like a stupid firewall issue until several hours later you realise that it's a "minor config difference" !!!

To put it bluntly, "why should the ****! ****! ****! application try to make a connection that it knows is going to fail?"

But, it is also a (minor) security issue in that it can potentially hide an attack. If you know you have a wrongly setup node it would be quite reasonable to see continual "failed attacks" in the application. Even if you don't think you have a misconfigured node it actually becomes a more reasonable diagnosis than someone is trying to attack the peer. You lose part of the ability to monitor the security because something that should never happen (a connection with the wrong key) becomes a common, dumb, problem.

Use of different encryption & MAC algorithms is just the normal security stuff. If an attacker doesn't even know which algorithm you're using they either have more work to do (to find out) or they have to attack all algorithms are the same time. What's more the OpenSSL library can be upgraded and if the new version supports SSH3 then so can BTSync, immediately, without any extra updates.

[affinity]

OpenSSL library can be upgraded and if the new version supports SSH3 then so can BTSync, immediately, without any extra updates.

SSH3 SHA3 ... ?

[entwistle.mark]

kos13 indicated in this thread that SHA256(secret) is used (for external peer registration and matching via DHT and trackers).  If this is true why is SHA1 still indicated here ( http://www.bittorrent.com/sync/technology ) instead of SHA256 / SHA2?

 

 

[iguypouf]

I'm sorry to revive a very old topic.

 

However, i think that this threat is real, of course long secret keys bring down the risk of theft, but...

 

Why do you think about this suggestion :

 

" You can activate an option that require that a new device connecting to a shared secret should be accepted by another device ".

 

So, a device creates a key; if a second device try to connect, it should be accepted by the first one; just as bluetooth works.

 

As simple as today, but without any risks of accidental / unallowed connection.

[Jaman42]

Even more sorry to revive a even older thread but thought I could help someone who had security concerns. At first I was a bit skeptical about the security but that was only because I didn't quite understand it, I have been reading up everywhere it seems like and finally I am completely comfortable using the generated btsync secret for anything I want to sync.

 

The first thing I think confuses people that are new (like me) to how secrets work are that they look pretty short and simple. They are thinking, that's not very secure is it. Well it is....

 

On page two in this thread there are some simple calculation of a secret with very few characters, reflect upon that a bit. I also saw some calculations (not sure if it was another thread) roughly about how long it would take to brute force a single secret if everyone on the planet where trying millions of secrets a second. First of it isn't possible in practice to do this for a numerous of reasons, it's just another way for the people who knows trying to explain for the people that doesn't know (like me) how unlikely it is.

 

If your still not sold, I know I was a bit stubborn about it you can think of it this way. Wonder if there are a single one (script or human) out there sitting in their living room trying to guess secrets? I mean what would they do with it? If all the people on the planet where trying millions of secrets a second they still wouldn't find a active one in your lifetime. But if they did (they wont), but let's play with the idea that someone did eventually guess a secret (they wont), what are the odds that it is the secret you use to share your precious family photos?

 

As I see it now, the only way someone would access my data unauthorized is if I am being stupid with how I share my keys. I understand now that no other authentication method is needed for my share of family photos.

 

I enjoy the discussion, it's highly educational.