What is in .stfolder/syncthing-encryption_password_token ?

When i receive encrypted folder using syncthing, it creates following file:

{"FolderID":"xxxxx-xxxxx","Token":"DHhI/UIHUIIUZuDSDASADjHKJhiuTZTrDhgFhjgZgZUg"}

I was trying to find meaning of this file on google, but all i’ve found is that it “contains folder id”, which is obviously the case. But i am not sure what is the “Token”.

What is this “Encryption Password Token”? Is it important for successful decryption using syncthing decrypt? I know that i need to rememeber “folder id” in order to decrypt my files, but there was no mention about token.

What if i accidentaly delete this file? Will it get synced back?

It’s not required for decryption, though the folder ID is. The token is used to verify that the encryption password hasn’t changed, which would render the already synced data useless. I don’t recall if it’s recreated or an error if the file goes missing. In principle it could be recreated.

1 Like

So basicaly it is some known text string encrypted by the password? Does it help to verify that i’ve used correct password when doing syncthing decrypt so that i don’t end up with gibberish when i use wrong password?

Something like that, yeah. There’s no risk of gibberish regardless though, the encryption is authenticated – either you get correctly decrypted data or you get an error.

So when i change password on trusted node, it will cause untrusted node to resync all data (but this time encrypted with the new password) right?

It will throw an error on connection. You will have to either fix the password, or reset the folder on the untrusted node manually (as in remove folder in Syncthing, remove token on fileysstem, re-add folder). It won’t automatically resync anything, that would be bad (different connected devices syncing differently encrypted data).

Ok, thanks for clarification. And sorry for running into the details, i am just trying to fully understand behaviour of software that i am trusting with my data.

As long as Android is involved, there is a chance it will eat you data, so be careful.

:sweat_smile: what do you mean? like android might unmount part of the data while .stfolder is still in place so syncthing will propagate it as legitimate removal?

Anyway, so far my android seems to sync nicely.

And when we are already being offtopic, i’ve also added another syncthing node running on linux with ZFS, so i am doing snapshots every hour using znapzend. So far Syncthing+ZFS+Znapzend seems as perfect solution and i can highly reccomend it. I can sync between many consumer devices and have single znapzend server automaticaly keeping reasonable amount of history.

You can say that you want snapshot each hour for last 7 days, then each day for last two months and each month for last 3 years. Znapzend will then automaticaly create and delete old snapshots to keep just ones according to this plan. ZFS Snapshots are copy-on-write, so no extra space is used unless you actualy sync new contents. Also i run syncthing in container, which cannot modify snapshots, so even hacked syncthing will not be able to delete old snapshot. Very cool software stack in my opinion. Znapzend also can replicate snapshots to second linux server, but i don’t think that is necessary given i already have replicas in multiple syncthing devices in addition to ZFS.

I wouldn’t be at all surprised. See the other thread from yesterday about files disappearing mysteriously after certain patterns of renaming, for example.

This, though, is good. Carry on.

1 Like