How to restore and decrypt an encrypted folder if “forgotten” by both A (trusted) and B (untrusted)? E.g. if I make backups f the encrypted folder and need to restore that backup from a fresh install of Syncthing?
If you lost the password used to encrypt the folder you are out of luck. Otherwise there’s the syncthing decrypt command. The help (syncthing decrypt -h) should be self-explanatory - if not please ask, and I’ll try to improve it (and help of course 
).
Thanx! My “case” is when I still have the psw
I dont’ find the “decrypt” sub command, but I’m on the “stable release” channel (i.e. 14.0). Changing to also receive release candidates and will get back to you with my findings and result.
1 Like
For now if you test the untrusted/encrypted feature, you should use release candidates. Bugs are found and fixed promptly there.
Some findings after initial testing using Untrusted/Encrypted and CLI decrypt command. When doing everything “right” it works, but some special cases/questions below.
My setup is a Win10 PC (RC-channel, ST-version v1.15.0-rc.5) and a Raspberry (RPI4, stable channel and ST version 1.14.0).
-
In addition to the psw, you also need the “syncthing-encryption_password_token”, correct? If “yes”, this to be considered in a future topic “Decrypt & restore” in the usage documentation?
-
A folder encrypted using v1.14 can not be decrypted using v1.15.0.rc5. Not a problem considering early testing, using different/old versions etc, but for the future - Is it possible to secure backwards compatibility when the “untrusted” functionality is stable and released? My concern is that I want to make a backup of encrypted folders and still be able to decrypt in the future using a later ST version.
-
Off-topic, but anyway - Synztrazor (the Windows wrapper) automatically activates its’ file watcher on encrypted folders, thus making some change to the content in the encrypted folders and causing errors on those encrypted folder(s). Solution is to de-activated Synctrayzor’s file watcher for the encrypted folders.
I’ve been using ST for a long time now, it’s fantastic!
And this functionality for Untrusted/Encypted is making it even more fantastic, opening up for more use cases for which I before used Vercrypt container and separate encryption tool for backup to cloud!
2 Likes
No? There is a token, based on the folder ID, but it’s stored in the folder and should be picked up automatically by syncthing decrypt. If it is unavailable for some reason the tool needs to be told about the folder ID but not a magic token. What problem are you seeing?
There should be no change to the on disk format. Ideally not ever, and if there is then certainly the decryption tool must support the old format as well. What did you see?
Token/folder ID
- OK, tested again without the .stfolder but instead giving parameter --folder-id, and YES it works!
- So to decrypt I need to know the psw and the folder ID (if folder ID not available in magic token in .stfolder)?
Decrypt folder w different version (encrypted using v14.0, decrypting using v.1.15.0.rc) gives error “syncthing: error: 2.syncthing-enc\ET\L4FS4N6I615QSFSTV58MMBJR20SFCUL3O3U9VB2LP5S91FI598N9IG9K1ATBFDQ3MT5K4HBB57U37J095M: decrypting metadata: illegal base32 data at input byte 1”.
More on “Decrypt folder w different version” - After restarting Syncthing on untrusted side (v1.15.0-rc5) I get “Unexpected Items” for the encrypted folder.
Maybe not spend time on this issue caused in this special case (using v.1.14.0 on trusted side)?
After upgrading my RPI4 from stable v.1.14.0 to v.1.15.0-rc5 I still see the same problem (“Unexpected Items”), so I’ll do some more testing and provide an update on topic “Early testing…” when I can describe it properly.
“Unexpected items” might be old badness. Removing them with the button in the GUI should resolve. However I’m not sure about the cause for the base32 error you’re seeing. I’m not getting that with my encrypted folders which are older than 1.14.0 from the beginning. Can you run
syncthing decrypt --verify-only --password ... --verbose $folderpath
and see what it says? Is anything successfully verified? If so, is there an example of something that passes and something that doesn’t?
1 Like
Result from “verify”
Found folder ID: hfq7b-bwhkt Processing “0.syncthing-enc\BF\U680HENSUD36SMA0NVCRH0O89E5B88E7DIRS4U5SFMEPFIOOLAA6G5B7L7P5CGAEKEAK6FMJR58TLOV03QADGTA4IPQO” syncthing: error: 0.syncthing-enc\BF\U680HENSUD36SMA0NVCRH0O89E5B88E7DIRS4U5SFMEPFIOOLAA6G5B7L7P5CGAEKEAK6FMJR58TLOV03QADGTA4IPQO: decrypting metadata: illegal base32 data at input byte 1
The folder has been encrypted/shared from “v1.15.0-rc.5, Linux (32-bit ARM)”, i.e. a raspberry PI4, and received on a “v1.15.0-rc.5, Windows (64-bit Intel/AMD)”. It works fine in the other direction, the same data set is synced fine and decrypts fine, both on Linux/ARM 32 and Intel/Win 64.
Something to do with Debian/Raspian on ARM 32? And I think the same issue is also causing the “Unexpected Items”, which appears at the first scan AFTER initial sync. And the “Remove” action doesn’t help…
This might be the decrypt tool just not understanding backslashes. I didn’t twig on this being Windows at first.
I’ve been able to decrypt folder using the decrypt tool in Windows.
Then the folder was shared from, encrypted by, Intel/Win64 to ARM32/Linux and then copied to the Intel/Win64.
So data encrypted on Win64 decrypts fine on both ARM32/Linux and on Intel/Win64.
My setup is 1xPC Intel/Win64 and 1xRaspberry PI 4 ARM32/Linux (both on v1.15.0-rc5), trying different alternatives which side is trusted/untrusted.
- Works - Sharing/encrypting FROM Intel/Win64 TO ARM32/Linux, encrypted folder can be decrypted with decrypt tool on both Intel/Win64 and ARM32/Linux
- Not working (“illegal base32 data at input byte 1”) - Sharing/encrypting FROM ARM32/Linux TO Intel/Win64
2nd alternative also other issue/problem with “Unexpected Items” at first re-scan after initial sync.
Could be SBK (Skit Bakom Knapparna), I’m not a developer… But happy to continue to provide input if it’s a real issue and it helps.
The issue is that we save the encrypted file info in native format (backslashes on windows), while the decrypt tool uses the protocol library, which expects wire format (always slashes). So it should always fail if the untrusted/encrypted side is windows. I’ll post a fix soon.
1 Like
Hi again!
Re-tested after update to v1.15.0, now CLI “syncthing decrypt” works on Windows.
However, a new issue that maybe also relates slashes/backslashes?
When sharing folder from Linux/Trusted (T1) to Windows/Encrypted (U1);
- Adding folder with encrypted data to U1
- Waiting a while for folder to sync (works fine)
- After first sync completed, at first re-sync (e.g. after restarting ST, re-scanning folder or pause/resume) I get “Unexpected Objects” on the U1.
I don’t see the issue when sharing the other way, i.e. from Windows/Trusted to Linux/Encrypted.
I’m seeing the same thing too. Linux to Windows the first sync works fine, but then after a while the Windows side of Syncthing says that there are locally changed files and errors with
directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally
1 Like
Interesting, thanks! It’s high time I ripped that functionality out anyway (it’s been disabling itself if it sees Syncthing’s file watching in use)
1 Like
To Antony - I’m not sure that Synctrazor’s file watcher actually caused any problem by making any changes (?) to the ReceiveEncrypted folders, just that Synctrazor initiated the 2nd scan and thus triggered the Encrypted folder(s) on Windows reported as “Unexpected Objects”.
BR/
It should do the same thing as clicking the “Rescan” button (albeit targetted to the folder which changed)