why not use an encrypted bittorrent file as the mechnism of implementation?

Feature
1

I am kind of confused about the overall security model for syncthing. Why is there such a convoluted process of creating a node ID on both sides of the connection, and then creating a repository ID within that? On other threads there is discussion about the superior security of this approach, but more recently it seems like the “introducer node” model is essentially making that claim (which is kind of uncompelling to start with) moot.

I like syncthing better that btsync, since it’s open source, but with btsync the security model seemed very easy to understand: if you know the password for a repo, you can open it.

It also creates the possibility of community-style support: if you set aside 1GB of your HD to host someone else’s encrypted torrent file, you will receive 1GB of redundant storage on a foreign machine for your own torrent file.

The advantage is that it doesn’t /matter/ where it resides (or who else has a copy). You simply compute a sufficiently complex key, and anyone who wants it can have it. Your data is probabalistically protected based on the key you chose.

From an implementation standpoint, this seems remarkably straightforward as well, plus you get all the benefits/efficiencies of peer-to-peer distribution for free. Basically, you would have two representations of any repo: the encrypted, and the unencrypted versions. For any given repo, you create a self-signed 2048-bit certificate. The public key of the cert becomes the repo ID, and the private key becomes the repo password. You can make a chained certificate for read-only permissions.

Anyone can copy the repo by putting in the public key, but only those with the private key can see the contents.

The thing that bugs me about having to add both peers to a relationship (besides the extra step) is that it’s a bit like “security through obscurity”. Adequaty crypto assumes that the attacker has the full message text. So why not just assume that as a starting point, and build whatever cryptographic guarantees you need to on top of it to satisfy yourself that your secrets are safe?

The files would then by encrypted in a way similar to any encrypted file system like LUKS or ZFS on a block-by-block basis.

This seems like such a powerful way to share the data, and to keep the code base clean (by separating the peer-peer aspect with the encryption aspect): win-win.

2

There is no security through obscurity here, and the repo ID isn’t part of the security of the solution really. I suggest you read through the “how node IDs work” FAQ article to familiarize yourself with how it actually works.

I’ll have to admit I’m not at all knowledgeable about how bittorrent sync’s security works under the hood. When I last looked at it, which is more than a year ago, it was unknown/undocumented and not obviously safe in any way.

3

Thanks for the pointer. Helps a lot.

Now I understand better. Thanks for the explanation in the FAQ.

But the private key is required to decrypt the communication, right? I couldn’t really tell based on the FAQ how the private key was subsequently used.

The normal criticism of “security through obscurity” is made because it’s used in lieu of cryptographic (=mathematical, =probabalistic, =“real”) security. In the case of Syncthing, I think you have both, and don’t need it. And it’s not true STO (how could it be… it’s open source). It’s more that you are trying to prevent the attacker from evesdropping. But if your security is real enough, you don’t need to. Just assume the channel is compromised (because it is even if you don’t assume it), and depend on public key encryption to maintain privacy.

4

Thing is though, it’s just regular TLS. It’s true what you say, the communication is secured, not the actual data on disk. That’s the design decision from day one. I’d say that the fact there’s nothing secret involved in setting up the security is a win - i.e. there are demo screenshots all over the place with my actual device and repo ID:s, and that doesn’t lower the security of my data one bit.

But it’s a loss if the use case is to keep data on an untrusted computer, for example.

2 Likes
5