Untrusted Device Encryption(docs.syncthing.net)
docs.syncthing.net
Untrusted Device Encryption
https://docs.syncthing.net/specs/untrusted.html
60 comments
> The string “syncthing” with the folder ID concatenated make up the salt
Meaning its not fixed but every folder has its own salt
Meaning its not fixed but every folder has its own salt
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.
[deleted]
I think you're right. Reported on Syncthing forum. https://forum.syncthing.net/t/entropy-of-untrusted-device-sc...
>> 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.
> 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.
the folder ID is a (from memory) 6 character random alnum string.
this is more than adequate for a salt.
this is more than adequate for a salt.
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.
Maybe we can wave this as good enough, but cryptography usually has higher standards.
These don’t refer to individual directories, only top level syncthing folders. Nobody in their lifetime is making even 1000 of these.
> 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.
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.
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
[0] https://github.com/peergos/peergos
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.
Defining covered threat models would be useful, though.
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.
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.
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.
There’s nothing wrong with using an SD card. I use Syncthing on rpi with a 1TB SD card and it works great.
I think you are missing the point. If you fully control the hardware, then you probably don't need Untrusted Device Encryption.
It's also a poor solution for an "always on" solution since it's dependent on your home Internet/VPN/power working, which is probably true for your other clients too.
If I'm running Syncthing on a desktop computer at home and a laptop with me on the go, adding a Raspberry Pi to the same home network doesn't really improve resiliency of the sync service. But if I have a server in a completely different location, it actually will.
If I'm running Syncthing on a desktop computer at home and a laptop with me on the go, adding a Raspberry Pi to the same home network doesn't really improve resiliency of the sync service. But if I have a server in a completely different location, it actually will.
Who on earth leaves their desktop running when leaving the house? Why?
That's not entirely true. For example your Raspberry PI can get stolen.
I would definitely encrypt the stuff on my NAS if it was sitting in my garage.
I would definitely encrypt the stuff on my NAS if it was sitting in my garage.
Sure, but the tried and true way to encrypt your NAS would probably be using full-disk-encryption, not something specific only to syncthing.
If someone manages to access the running raspberry pi though, FDE doesn't protect against that, while the Syncthing's untrusted device encryption does.
Including if some other service on your Pi gets compromised. They still won't get access to your synced data.
If your threat model includes someone willing to break into your house, then, well, good luck. [0]
[0]: https://xkcd.com/538/
[0]: https://xkcd.com/538/
The threat model described by the post above you is actually not about physical access. It's about the PI getting hacked remotely.
If you use Syncthing's encryption then at no point is the decrypted content available to the PI. It gets decrypted locally by other Syncthing peers after they have downloaded it.
If you use Syncthing's encryption then at no point is the decrypted content available to the PI. It gets decrypted locally by other Syncthing peers after they have downloaded it.
Besides, there's still a difference between physical accesses: plain and non-targeted (besides how profitable they're expected) burglaries are way more common than violent targeted attacks meant to extract a secret from an individual.
Are you aware of any non-targeted burglaries where the burglar extracted secrets from a running computers memory?
An attacker with a wrench will get the information they want from you, regardless of where it's located.
Maybe a better example might be wanting to use a smartphone as the always on sync endpoint. The phone can easily be stolen but with this feature it won't contain the valuable data.
How do I start the NAS up, SSH in and type the password?
You send it a WoL packet[0], use key-based SSH to log in to the initramfs environment[1], and type in your password. Or if you have a TPM you can just stick encryption keys there. Do note that if the device lacks secure boot or such, this is vulnerable to an attack where the initramfs is modified to steal your password; how bad this is depends on your threat model.
[0] https://en.wikipedia.org/wiki/Wake-on-LAN
[1] https://askubuntu.com/questions/1269981/unattended-headless-...
[0] https://en.wikipedia.org/wiki/Wake-on-LAN
[1] https://askubuntu.com/questions/1269981/unattended-headless-...
Depends on the setup, disk encryption has disadvantages such as needing to decrypt each time you reboot (and if that's the root partition, you can't really boot unattended). It can be advantageous to not have to trust the server and have a non-encrypted zfs dataset for this.
I've used dropbear-initramfs on both Debian and Ubuntu to remote-unlock hosts with encrypted root filesystems successfully. It'd be nice if it were better supported though.
https://www.cyberciti.biz/security/how-to-unlock-luks-using-...
https://www.cyberciti.biz/security/how-to-unlock-luks-using-...
You could also have a Raspberry to backup in another place, such as a friend's house.
I understood that point. The raspberry pi would still serve as an always on endpoint regardless of the untrusted device encryption feature.
In my case I don't use this feature on the pi, but I do use it on my phone which has 256gb storage. I have configured syncthing to only run when charging the phone, so it is not always on.
In my case I don't use this feature on the pi, but I do use it on my phone which has 256gb storage. I have configured syncthing to only run when charging the phone, so it is not always on.
Yes you do. Any device that doesn't support good enough fde should have syncthing encrypted. Because usually you want the device to boot and start operating unattended - it is quite vulnerable.
I agree with this. FDE for semi-autonomous network devices is just so you can more safely dispose of the drive at end of life.
I would like FDE + untrusted device encryption for a NAS. I am glad Syncthing is working on this.
I would like FDE + untrusted device encryption for a NAS. I am glad Syncthing is working on this.
Not necessarily. Lets say I have a node at my in-laws house. I would use untrusted device encryption in case anyone decided to take the drive and have a look.
[deleted]
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.
[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.
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.
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.
Is it a problem if the disk is encrypted ?
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.
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.
If a user has access to your machine to steal the password, why not just steal the data that's protected by it? Or add another device to syncthing? Install a keylogger. Rootkit.
Generally it depends on the threat vector.
* Do you trust the hardware
* Do you trust the OS
* Do you trust the user
* Do you trust the software
On a rootkit you don't trust the OS anymore. So a safe location inside the OS space isn't an option anymore. But often you are not a root user (e.g. android, windows in a corporate environment)
If you have OS backups there is a risk it is readable by others (e.g. cloud, different IT department). There is also a risk a user uploads the config somewhere.
If you want to rotate keys you would have to search all keys compared to a centralized location.
* Do you trust the hardware
* Do you trust the OS
* Do you trust the user
* Do you trust the software
On a rootkit you don't trust the OS anymore. So a safe location inside the OS space isn't an option anymore. But often you are not a root user (e.g. android, windows in a corporate environment)
If you have OS backups there is a risk it is readable by others (e.g. cloud, different IT department). There is also a risk a user uploads the config somewhere.
If you want to rotate keys you would have to search all keys compared to a centralized location.
I wonder if some system akin to Clevis + Tang would solve this?
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.
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.
> The untrusted device will be able to observe:
> File sizes
> Which parts of files are changed by the other devices and when
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.
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
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
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
Who knows if I'll ever build it but if someone else wants to I'd love to see that happen
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.
The only advantage I can think of I suppose is that this is "real time". But it's a pretty small perk.
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.
i've been using it forever ... I think it's just the untrusted device thing that needs a password, just go to settings -> sharing ..
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.
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.
I've been using syncthing to synchronize encrypted files and obsidian files (separate use cases) and I'm quite happy. Just one data point.
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.
BTW: 'worried' as in 'code smell', not 'worried' as in 'the encryption can be easily broken'.