Fix/Incorporate Encryption/Decryption passwords with the 3x 'Folder Types', rather than adding more Folder Types.

I am aware the Encrypted/untrusted device feature is currently beta, however I would suggest incorporating the encryption function in the existing forms of folder types (eg Send Only, Receive Only, Send & Receive).

To enable encryption, one simply sets a password on a folder. This will enable encryption when sending and/or receiving folder data. This is inline with the current encryption function (eg the device with the password encrypts the local data went sent to other devices), but also allows each file to be encrypted from any sending devices. Each device can encrypt its own local file data, and optionally if the passwords are the same on each device, then the file(s)/folder data can be ‘sent encrypted’ → ‘receive to be decrypted’. This will also harden data, with encrypted data transfers (eg unsafe relays, interception, ISP’s, etc.)

Using encryption with the existing Folder Type Functions

Local changes with a folder password, get sent encrypted to the devices for:

  1. “Send & Receive” folder types, the device sends and accepts changes to the folder. If the other devices have the same password, then the data is decrypted accordingly and updates the data/file. If the other device does NOT have the same password or has no password for that folder, then the data remains encrypted and unable to be changed - so actis like a “receive only” for that file, unless the same password is provided.

  2. “Send only” folder types, the devices sends encrypted data only. If the other device has the same password, then the data is decrypted and visable. If the other device does not have a matching password, then the data remains encrypted and cannot be modified/changed/updated - acts like a “Receive only” for that file, unless the same password is provided.

  3. “Receive Only” folder types with password, if the device receives encrypted data (local changes are not allowed), and the device has no matching password for that file/folder, then BAU - receive only + non-visble file (encrypted). If the device has a matching password, then the data is decrypted and visible, but local data updates still do not propagate.

Basically (similar to the current way):

  • data sent (a-end) without a password set for the folder, OR with a password so data sent with encryption → data receivved with the same password (ie decrypted on the b-end) = BAU 3x Folder Type functions.
  • data sent (a-end) With a password (ie encrypted) → no matching password = Data received encrypted and remains encrypted.

However, allowing the 3 folder types WITH a password on the receiving devices allows those devices to manage their own source data/files when sending to the cluster, as per current folder types but WITH encryption.

(To turn off encryption, one either uses the same password on each device OR one simply does not provide any passwords for that folder on any device (as per current).)

Also, using a Seamless Transition for Encryption <-> Un-Encryption

Also, the ability to simply switch encryption on/off needs to be fluid. When changing from non-encryption to encryption, one should simply add a password to enable encryption (transparent re-sync of encrypted data should occur removing unencryted data…rather than a folder re-add) and when encryption is disabled/removed, Syncthing should resync all existing data un-encrypted transparently without the need to re-add the folder…

Using a password to encrypt (and optionally decrypt on the receiver) also functions to determine if file/data changes are able to be sent/received or both. This is similar in principle to the 3 Folder types logic, only instead of the uncahngable data being readable (unencrypted), its unreadable (encrypted).

1 Like

I am lost to what the benefits are here.

If you want files encrypted in transfer, you setup an encrypted folder and set the passwords.

The other cases don’t make much sense, because you don’t know the types of things ahead of time from all devices.

Two supposedly receive only encrypted devices connect for the first time, neither have a password set, assume it’s all fine and set a folder type, now a third device (the real source device) comes up, starts sending data with a password, at which point the folder type makes no sense.

Whats worse is you could have a conflict where two peers are sending you data, one encrypted, one not, what folder type do you pick and how do you handle it?

You are forced to set things explicitly to avoid ambiguity and for things to abort when expectations do not match.

Also, always encrypting data is not free, so I am sure people running syncthing on low powered devices would not appreciate it.

2 Likes

Also, the whole seamless thing is impossible without incredibly complicated machinery that allows you to “revert back” in case something goes wrong.

It simply cannot be done as an atomic operation, so needs either double the space or some sort of magical transaction log (with pretty much double the space) that allows handling failures, abrupt power cuts etc.

1 Like

Also, the whole seamless thing is impossible without incredibly complicated machinery that allows you to “revert back” in case something goes wrong.

It simply cannot be done as an atomic operation, so needs either double the space or some sort of magical transaction log (with pretty much double the space) that allows handling failures, abrupt power cuts etc.

There would only be 1 source of truth - the sending device (unencrypted), which does not require anything extra since it doesn’t change. All other devices just get their files replaced with encrypted ones. To revert back would simply be a matter of re-sending the orignal source device files (unencrypted).

1 Like

I guess thats partially a destructive action, as you will be deleting data, and hope (no guarantee) that could redownload it, so doing this just because someone added or removed something from an edit box feels dangerous. You’d need warnings an explanations.

For the same reason we also don’t allow modifying folder paths, and ask users to jump through hoops of removing and adding a folder, to declare their true intent.

I agree, all of these could be smoother, and could be solved, but if anything, the folder path change is probably more pressing, yet we never cared enough about it to address it.

Also, the UI code is quite old and hard to extend, making building these user experiences hard.

1 Like

That does not change, except to enable data access control for multi-user devices, giving the ability to control access to the files for selective devices, eg the ones that have the folder password (ie decrypt = files accessible, encrypted = files not accessible), and still utilizing the cluster storage (encrypted/un-encrypted). This is how it ‘may’ already work, but I don’t see a “Send & Receive encrypt/decrypt” folder type (not that it would be needed if implemented the suggested way).

They’re not encrypted “devices” they’re encrypted “folders” ie regardless of the device, the folder is encrypted (or not) on the cluster (except for the devices that have the folder password to decrypt). The receiving device will either have a password to decrypt the folder (entitiled) or not (unentitled). There will never be both, since if the folder is encrypted then only devices with the folder password can decrypt the data and also encrypts on send. If a device does not have a password for that folder, then the folder data will be encryted (no access to mod/view/change, etc.). If the device has the folder password, then the data will be decrypted on that device regardless of where it gets it from (encrypted or not). The folder encrytion starts with the sending device that has a password to encrypt the data on the send, so if a folder has a password on ANY device, then that folder will be an encrypted folder on the cluster. This would work visa versa for decryption.

This would never happen, see above on how it works.

No-one is forcing users with low powered devices (such as myself) to use encryption. You may as well say that for the current encryption option. The option of also decrypting on the end device allows users/admins to chose how to manage the data.

Syncthing has covered filesharing/syncing very well. The current encryption feature goes outside the scope of filesharing (since once the data is encrypted, there is no access to the shared data) and gone into syncing/redundeancy - utilizing the cluster to ensure redundancy via encyption is a very good feature, secure with some disaster hardening. My suggestion is to allow both scopes to interchange, and make it more flexible/usable by allowing decyption on shared folders via password unlocking and using the existing Folder Types (with or without password set) to do it with. This will avoid the need to add new ‘folder types’ since once a password is set for a folder, it is simply classed as an encrypted folder for those devices that do not have the same password to decrypt it.

This could also be extended to allow devices that have already encrypted folders be used as normal folders and still retain the encrypted data ie the folder could contain (local) unencrypted or (remote) encrypted data. Additionally, one could then encrypt their own local data with their own password, in the same way as above. However that would involve hiding encrypted data in a special ‘.encrypted’ folder for it to work (and keep locally un-encrypted in the normal folder structure, for ease of use and to allow users to still use the same folder as normal unencrypted data and still store encrypted data which isn’t usable anyhow. There would also need to be a password manager matrix eg ‘Folder Vs Device’ in a XY grid for each password, etc.) to ensure each folder password is captured depending on the device. Then the “Send Only” and “Send & Receive” can utilize both encrypted and unencrypted data in the same folder PER device. Then the method would work similar to all of the above…but that would be for another post.

Not sure what you mean - syncthing deletes data all the time when files are deleted from source. I presume you mean loosing data? I would have thought the file conversion would be as follows (mistake proof):

  1. Encrypt the file to send
  2. Send the encrypted file, then
  3. Once confirmed the encrypted file has arrived *, then remove the un-encrypted version.
  • If any error(s), then revert the last file back (ie either remove the encrypted version, or if the un-encrypted version was nuked, then resend the un-encrypted version then nuke the encrypted one)
  • If requested to undo it all, then just do the process in reverse (file by file) or just do a full re-sync with reverse state date/files (eg un-encrypted data, then nuke encrypted, etc.)
  • Any major issues would still require admin to intervein, so syncthing would simply alert of the issue in the logs (eg h/w issues, not related to syncthing, etc.), so allow a pause/grace period once fixed, yncthing can continue with its reversion or continuiance.

That way there’s no possibility of losing data. Sure there may be some extra space used, but syncthing-.tmp files use up to the same when transferring anyhow.

That would be for a very good reason - the folder structure for one could be completely different and mass changes like that are irreversible and too difficult to track for any undo’s.

I wouldn’t suggest changing folder path (since that would be a different issue), just changing the existing folder contents to encrypted files automatically - keep the same path. Converting the folder to encrypted shouldn’t require a new folder. One can just simply create a new encrypted folder anyhow (as is). By using a File-by-File conversion it will automated conversion once encryption is enabled, and allow for validation per file conversion and the option of reversion if required, rather than manually re-initiating the same data with new folder.

I understand your idea as the following - though there’s a lot of text here, so I might have missed something:
While to day every Syncthing folder needs to be configured correctly, i.e. has either plain data or encrypted data with the one correct password, you want to allow all of it at once. A folder can contain multiple copies of the same data, i.e. one plain, and infinitely many copies encrypted with different passwords. Correct?

What would the benefits or potential use-cases of this be? The downside is obvious: Huge complexity both for users (there will be a myriad of weird configuration issues, folders can explode in size, …) and on the implementation side.

No, not at all. Sorry about the high text count - the idea is easier to explain verbally than via text.

It could be seen as using encryption as a simple “file access/visibility” trigger for those devices that have the same password for the folder. If/when encryption is enabled (ie password provided on the first device), the files are either encrypted or not on the b-end device(s). There are NO duplicate/multiple files.

The main point is as follows:

  1. Current syncthing works as per this image when there is no encryption on a folder (ie no password set):

  2. Currently when a password is provided, the way it works (from my understanding) is as follows - all b-end devices have the folder locked into encrypted files with “Receive Only - Encrypted”

  3. What I’m proposing is to allow each device to determine if the folder is left encrypted or decrypted in the following way (via providing the password on the device):

You get the idea on the 3rd image - This will allow control on which device(s) can still have access to the folder (or not).

There would (ofc) initially be some scenarios that change the folder type since a “Send Only” folder that is encrypted becomes irrelevant, since encrypted data cannot be changed on the local.

ps As an aside for possible future use in a multi-user environment, allowing local additions to a remotely encrypted folder, can be of some benefit - eg allowing users to still use the same folder and add NEW files of thier own (as unencrypted data), allowing them to share on the cluster…but I can explain that further in a new post later.

Firstly let me get something out of the way - maybe it’s related or not at all: A folder containing encrypted data being set in the UI as a folder-type is a bit special and maybe confusing. As the “receive-encrypted” type works differently from the others, in that you can only choose it when creating the folder. One might argue it should be a boolean checkbox, and disable the folder-type selection when checked.

Now I am still not sure I understand. To me a single example would be helpful. E.g. in your images, are these time series from left to right and 3 scenarios from top to bottom, or the other way around?

Is this about being able to change from a receive-only folder, i.e. having encrypted data, to a any other folder type, with plain data, by providing the password? That’s of course doable, it’s just not implemented. Currently you need to remove the folder, use the syncthing decrypt tool and then readd the folder.

Although I’m not completely familar with how the current system works with encryption, I have noticed several functions that cause major issues with it. I understand its beta, so its a process. My main purpose was to approach it slightly differently by using the existing framework of the 3 folder types only. Setting a password implies encryption anyhow, there is no need for a special folder type with encryption.

Image 1 shows all scenario combo examples - i just layered them in 3 rows as it was easier to see all combo examples eg 1st row = Device having “Send Only” folder shared to 2 other devices with each combo ‘Folder Types’. The 2nd layer was with “Send and Receive” and the last row was with “Receive Only” (although most of these are already covered in the prior 2 rows anyhow).

The 2nd image shows the all of the current Encryption scenarios.

Image 3 is based on image 1 (same 3 folder scenario combo’s) but incorporating how encryption should overlay it.

The idea is that if a device that has the folder password, the folder contents are decrypted. If it does not, then the folder contents remain encrypted.

One end objective is to allow multiple encryptions from a shared folder to allow users to keep using the shared folder and also store encrypted data (say in a hidden .stencrypted folder), so it doesn’t make that folder unusable to Syncthing (eg “My Documents” for example, one would want all users on all devices to still use My Documents", even if 1 of those users encrypts THEIR documents only. Other users could also encrypted THEIR documents and selectively give access or not to whichever device they wanted to, etc.).

For example, in a family environment I may want to encrypt my poetry and personal notes on the kids computers (kids hav a way of hacking any folder in Windows, so if encrypted there’s no way to view the files), but allow my partner access to them from their computer, etc…

For another example, if I have 3 friends and I want to share the ‘My Pictures’ folder to only 1 of them I would encrypt the folder and allow decryption that 1 (eg provide the folder password to decrypt the folder data), and the other remain encrpted - they all can still use their “My Pictures” folder on their pc’s. Any one of them can do the same with their pictures if they wanted to, by setting their own password for their own pictures. This would not affect my pictures, nor would it create duplicate files since my would already be encrypted separate from theirs.

Partly yes - the intent is to remove any need for additional Folder Tpes (there is no need for them) by recognizing if a folder has a password, then its an encrypted encrypted (why have a password otherwise). The way the current encryption works however will cause conflict issues with 2+ unencrypted devices sending to 1+ encrypted devices if those 2 unencrypted devices have different passwords - and cause syncthing to go crazy.

The ability to change from an un-encrypted to/from encrypted folder was covered in prior posts, but briefly ‘mistake proof’ steps would be something like:

  1. From the device that has a newly created/modified file, before it sends to other devices → Encrypt the file ready to send
  2. Then send the encrypted file,
  3. Once the encrypted file transfer has completed and cofirmed successful, then remove the un-encrypted version (if found)

Any errors can be re-tried or undone on a file-by-file basis eg complete reversion just done in reverse. Also to convert a folder from encrypted to un-encrypted, the process is done in reverse. This is a different component from the Framework of keeping the 3 Folder Types without the need to introduce more from above.

While testing the current encrption function in Syncthing, I noticed that to encrypt the folder per device one specifies the folder password per device. I would guess this would be the best way to allow for multi-user encryption.

eg from Device 1 for “Send Only” or “Send & Receive”, set:

  • Folder 1 → Password for Device 2 (encrypts the folder content on Device 2)
  • Folder 1 → No password for Device 3 (does not encrypt the folder contends on Device 3)

However, because one cannot currently change the Folder Type from “Receive Encrypted”, Folder 1 on Device 2/3 is unusable.

If one can change the ‘Folder Type’ on Device 2 to (say) “Send & Receive”, then the user on Device 2 can either set their own password and encrypt the folder data/files they create (since Device 1 data is not accessible on Device 2 anyhow, there’s no file doubling up), OR they don’t set a password and their newly created files get shared on the other devices. There would be issues that would need to be worked out for when Device 1 and Device 2 have files named the same, since Device 1 encrypts it on Device 2 and so Device 2 would not know if that filename is already taken.

The user on Device 3 has access to the folder data from Device 1, and 2 if no password was set for that folder on Device 2 - however if there was a folder password set on Device 2 for device 3, then device 3 will not have access to Device 2’s folder files since they’ll be encrpted (and not accesible) - Device 3 can stil use the same folder, but only from Device 1 (unencrypted) and newly created Device 3 files will be shared.

for the file duplication issue, Syncthing could prevent syncing back to a device that is encrpting folder data from, if un-encrpted back

eg If Device 1 encrypts folder data and is set to “Send & Receive” (or any folder type really) and if Device 2 has the same folder set to “Send & Receive” or “Send Only”, then

  • If Device 2 has the same folder set with a password (ie enable encryption), then the new data can be sent to Device 1 without issues (since Device 1 folder data is encypted, there is no way Device 1 folder data will be changed/modified, etc. on Device 2),
  • If Device 2 does not have a password for the folder (eie not encrypted), then Device 2 needs to prevent syncing back to Device 1 otherwise there will be file/data conflicts.

There’s quite a few mis-conceptions about how encryption works here (e.g. there isn’t a single password per folder), and I still don’t get what you are after in the end (still not being helped by the verbosity). Feel free to give short, concrete use-cases and I’ll try to explain how they work in the current scheme, or why they don’t and if/how the use-case or Syncthing could be adapted to make it work.

1 Like

Likewise, I tried to read and understand it, but the fact it’s so much text makes it not possible to understand the idea.

1 Like