Untrusted Device Encryption
docs.syncthing.net
docs.syncthing.net
BTW: 'worried' as in 'code smell', not 'worried' as in 'the encryption can be easily broken'.
Meaning its not fixed but every folder has its own salt
> 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.
this is more than adequate for a salt.
Maybe we can wave this as good enough, but cryptography usually has higher standards.
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.
Defining covered threat models would be useful, though.
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.
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.
I would definitely encrypt the stuff on my NAS if it was sitting in my garage.
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.
[0] https://en.wikipedia.org/wiki/Wake-on-LAN
[1] https://askubuntu.com/questions/1269981/unattended-headless-...
https://www.cyberciti.biz/security/how-to-unlock-luks-using-...
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.
I would like FDE + untrusted device encryption for a NAS. I am glad Syncthing is working on this.
[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.
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.
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.
* 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.
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.
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 would be happy to hear about opinions about this approach.
[1] https://nuetzlich.net/gocryptfs/
[2] https://github.com/rfjakob/gocryptfs/issues/549#issuecomment...
Who knows if I'll ever build it but if someone else wants to I'd love to see that happen
The only advantage I can think of I suppose is that this is "real time". But it's a pretty small perk.
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.