Untrusted Device Encryption

https://docs.syncthing.net/specs/untrusted.html

by tosh • 3 years ago

150 57 3 years ago

docs.syncthing.net

Sprite_tm• 3 years ago

Am I the only one a bit worried about them using a fixed string as a salt? A salt is intended to make it hard to create a rainbow table. I don't know how much entropy is in their 'folderID' variable, but given that it's a 'short string', it seems low-entropy and not random. If so, the current implementation makes it trivial to make a rainbow table. That means that if you can get the passwordtoken and know a folderID, you can create a rainbow table that maps all possible passwordtokens to valid passwords.

BTW: 'worried' as in 'code smell', not 'worried' as in 'the encryption can be easily broken'.

dpc_01234• 3 years ago

I think you're right. Reported on Syncthing forum. https://forum.syncthing.net/t/entropy-of-untrusted-device-sc...

scoot• 3 years ago

> Is it less safe to share the “Default Folder” as encrypted then? Its folder ID is always just 'default'.
In the sense that someone could easier pre-brute-force all passwords for that specific folder ID, yes.

That's the definition of a rainbow table, and a fixed, known folder ID makes the "salt" effectively worthless.

h4kor• 3 years ago

The string “syncthing” with the folder ID concatenated make up the salt

Meaning its not fixed but every folder has its own salt

halJordan• 3 years ago

The question is how trivial is it to get the folder id. If it's just an incrementing integer, is it really providing a good salt? Im not actually asking that question or asserting that it isnt, just explaining what you missed.

sneak3• 3 years ago

the folder ID is a (from memory) 6 character random alnum string.

this is more than adequate for a salt.

notfed• 3 years ago

That would mean each salt is about 36 bits. If you create 2^18=262k folders in your lifetime using the same algorithm and same password, there's a 50% chance one of the salts is dup'd.

Maybe we can wave this as good enough, but cryptography usually has higher standards.

hardwaresofton• 3 years ago

This feature is really awesome, can't wait for it to stabilize because it makes it possible to offer a sort of syncthing-based backups' backup by making available untrusted storage servers.

Who knows if I'll ever build it but if someone else wants to I'd love to see that happen

sourcegrift• 3 years ago

i've been using it forever ... I think it's just the untrusted device thing that needs a password, just go to settings -> sharing ..

LeoPanthera• 3 years ago

For backups, I don't see what this offers that borg doesn't. And borg also offers multiple snapshots, which this doesn't.

The only advantage I can think of I suppose is that this is "real time". But it's a pretty small perk.

plagiarist3• 3 years ago

I'd try borg, but I need more of an archival software. A number of large files that I don't want to gather all in one place every time I run the backup command. I'm trying out git annex for now.

zshrc• 3 years ago

Would work great on a VPS endpoint to guarantee “always-on” syncing (plus a VPN tunnel). I won’t touch it until it stabilizes though.

tarruda4• 3 years ago

A cheap and nice self hosted alternative way to have an "always on" sync endpoint is with a raspberry pi 4 with SSD (don't try this with an SD card).

My current setup is running a wireguard server, syncthing and DuckDNS on the pi. I also port forward the wireguard port from my ISP's router.

With this, my devices are always connected to the VPN, and sync always works (and is fast!) like everything is on a LAN.

hamandcheese5• 3 years ago

I think you are missing the point. If you fully control the hardware, then you probably don't need Untrusted Device Encryption.

sneak3• 3 years ago

There’s nothing wrong with using an SD card. I use Syncthing on rpi with a 1TB SD card and it works great.

brunoqc• 3 years ago

Is this the same "untrusted device" feature that syncthing already had for years?

Yodel0914• 3 years ago

Seems to be. I've been happily using it for ages.

janzer• 3 years ago

It seems that this has been in syncthing about 2.5 years[1], is there something that changed recently to make this notable now?

[1] Initial release behind a feature flag in 1.15 on April 6, 2021 and without the feature flag in 1.16 on May 4, 2021.

aborsy• 3 years ago

How does it play with versioning? Like, if I edit a file gradually, there are going to be ever growing number of frequent versions. There is no deduplication in the encrypted node (I’m not sure if there is deduplication between versions in plaintext either). The storage could rapidly increase.

hiq2• 3 years ago

I expect that the encrypted patch is kept instead of the full version because of this, see also what "the untrusted device will be able to observe" in the linked doc.

Saris• 3 years ago

As far as I know there is no deduplication in normal mode either, versions are just full copies of the file.

tarruda4• 3 years ago

My biggest problem with how this feature is implemented is that the encryption passphrase is stored in plain text in the syncthing config file.

I wish there was a way to lock the passphrase in the session keyring, with syncthing only sending files to untrusted devices if the keyring is unlocked.

sdeframond• 3 years ago

Is it a problem if the disk is encrypted ?

kenniskrag2• 3 years ago

yes because more than one process can access the file.

A "password manager" provides a defined api and schields the password away from everything. It can also ask the user if process x can access the key y.

babuskov• 3 years ago

I wonder if some system akin to Clevis + Tang would solve this?

tarruda4• 3 years ago

Not familiar with `Clevis + Tang`, but the way I would solve is my implementing an IPC mechanism where an external process can provide the encryption passphrase.

This would allow syncthing to start at boot, but untrusted devices would start in paused state. Once an external process connects and provides the passphrase (libpam module for login integration?), syncthing would start syncing devices which require the passphrase.

comex• 3 years ago

In addition the untrusted device must not be able to modify, remove or introduce data by itself without detection.

It sounds like that property is satisfied on a file-by-file level. But what about between files? Can the untrusted device delete some files without it being detected? Or un-delete deleted files? Or selectively revert files to older versions? The documentation describes how each file gets a signed blob containing the file’s metadata and hashes of its contents, but there’s no mention of any signed structure containing the state of the directory tree as a whole. So judging (only) by the documentation, it sounds like the answer to all of those questions is yes.

YMMV on how big of an issue that is. It helps that the attacker theoretically shouldn’t know which file is which. But imagine, say, a Git checkout of an open-source codebase being stored in a Syncthing folder. The attacker can guess which file is which based on file sizes and modification patterns. At that point, selectively reverting files might be able to mess up the code being stored, or associated configuration, in a way that creates some sort of vulnerability.

Apologies if I’m misunderstanding the security guarantees; again, I’m only going off of what the linked page says.

whatevaa• 3 years ago

You are expecting too much. You want something like noise protocol (like Signal does for messages) but for files, plus guarantees of a blockchain. Ensuring deleted files are not kept is impossible. Use encryption containers such as Veracrypt, where all files is just a big binary blob, if you want that.

Defining covered threat models would be useful, though.

ianopolous• 3 years ago

You might be interested in Peergos[0], where the server is treated as an adversary, and can't see file sizes, number of files etc. Everything is in merkle trees whose roots are signed. So not possible for a mirror to selectively remove a file, or add an old version of a file. They don't even know what constitutes a file.

[0] https://github.com/peergos/peergos

planede• 3 years ago

  > The untrusted device will be able to observe:
  >   File sizes
  >   Which parts of files are changed by the other devices and when

I know that cryfs[1] is resilient to at least the first of these, and possibly the second as well. I don't know if cryfs allows to modify the base directory while the filesystem is online, if it does then it might already be a better solution for syncthing, if you only care about Linux.

On the flip side syncthing could incorporate cryfs's base directory format instead of their home-grown one.

[1] https://www.cryfs.org/

edit:

https://www.cryfs.org/tutorial says the following about concurrent access to the basedir:

"Warning! Never access the file system from two devices at the same time. This can corrupt your file system. When switching devices, always make sure to stop CryFS on the first device, let Dropbox finish synchronization, and then start CryFS on the second device. There are some ideas on how future versions of CryFS could allow for concurrent access, but in the current version this is not safe."

Too bad.

StreakyCobra• 3 years ago

I'm looking to improve my documents syncing setup. Currently I'm using owncloud, but that seems overkill for just files syncing and it requires maintenance, so I gave Syncthing a look. The "Untrusted device encryption" was not appealing to me because I'm not convinced by the security aspects yet, and also because it is in beta for now. I used gocryptfs [1] in the past and was quite happy with it, so I'm planning to use it on top of Syncthing to have files synced encrypted. As far as I have read this setup (Syncthing + gocryptfs) seems to be used by several people and has already been discussed by gocryptfs' author, who recommended a `-sharedstorage` flag for such use case [2]. Reading [3] I think gocryptfs is more suited for files syncing than cryfs. I'm aware that the metadata (file size, structure, …) of my files are not encrypted but that's a compromise I'm ready to make.

I would be happy to hear about opinions about this approach.

[1] https://nuetzlich.net/gocryptfs/

[2] https://github.com/rfjakob/gocryptfs/issues/549#issuecomment...

[3] https://www.cryfs.org/comparison

sertbdfgbnfgsd• 3 years ago

I've been using syncthing to synchronize encrypted files and obsidian files (separate use cases) and I'm quite happy. Just one data point.

slaymaker1907• 3 years ago

Apparently, even synthing doesn't think oblivious RAM (ORAM) is worth it. For those who haven't heard about it before, it's completely possible to abstract over a block storage device such that an attacker can't even determine things like which logical blocks are written to most frequently/correlations between writes on logical blocks.

Unfortunately, even though there are algorithms make each access only take log(n)^2, ORAM by definition makes caches on the server side not work at all. If the server can effectively service requests via cache, that means they can predict which memory cells are most likely to be used.

Untrusted Device Encryption

Related Stories