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.