duplicati
duplicati copied to clipboard
duplicati
GPG asymmetric encryption module
It is currently possible to get GPG encryption working with a key, by setting the switches manually like this:
--encryption-module=gpg
--gpg-encryption-command=--encrypt
--gpg-encryption-switches=--recipient "[email protected]"
--gpg-decryption-command=--decrypt
--passphrase=unused
You also need to set the trust level of the key to 5, for example:
gpg --edit-key "[email protected]" trust
It would be nice if there was a module, say gpg-pubkey or similar that simply sets these options. Perhaps the passphrase could be used for the recipient, but that might get messy if you want to change it later.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
This would be great to have as a standard feature. I have to admit the described solution didn't fully work for me or better said I was unable to follow it due to my lack of knowledge. I didn't use the commandline tool but the standard web interface of Duplicati 2.0 and used Advanced Options and edited as text. When I was done and ran the backup I got an error "unable to change password". Also I have a question in regards to where do you put the key file? How does duplicati find the correct key to use since it doesn't refer to my normal gnupg4win folder. The pass phrase here is separate from the pass phrase of the actual key I am assuming, correct? I'd appreciate your help. However I fully agree that an option for asymmetric encryption in which you can specify your own pgp key would be something very desirable since this is the most secure option in my opinion.
@Antergosgeek You cannot change the passphrase of the backup, because Duplicati does not support more than one passphrase at a time. If you were able to change the passphrase, some files could be encrypted with one passphrase, others with another passphrase, and it would be impossible (rather: difficult) to restore.
If you use the GPG asymmetric setup, the passphrase here is actually unused, but a value is required because Duplicati enforces it.
I have not tried using GPG this way myself, so the setup is from other users. I do not know how GPG manages its keys. You can set --gpg-program-path to point to your gnupg4win gpg.exe file if that fixes things.
@kenkendk I found how the key management works it works through your gnupg4win installation. Also if you have set the PATH under environment variable in windows for your Gnupg installation e.g. C:\Program Files\GNU\GnuPG\pub then it will find it automatically. But thank you a lot for the help! Also you can set the password in the GUI but it needs to be identical to the keys passphrase just as described from you! I have tried this successfully with asymmetrical encryption with my own key with trust level 5 (ultimate) granted you entered a passphrase and it is the passphrase of your key in the GUI by setting the following options in STEP 5 under Advanced Options --> Edit as text:
--gpg-encryption-command=--encrypt --gpg-encryption-switches=--recipient "[email protected]" --gpg-decryption-command=--decrypt
The trust level of the key is set in a normal cmd prompt (Windows key + R --> CMD) then the above mentioned command then follow the on screen prompts. You can also do that in KLEOPATRA if you use gpg4win.
Is there a way to use the asymmetric encryption? I am currently using my own python scripts to zip and encrypt stuff. Duplicati looks amazing and quite configurable except the part of being able to use my gpg key to encrypt. Since I believe that is the most convenient and secure way for me.
I tried the above way but was unsuccessful. Was unable to change passphrase and also tried importing config but that failed due to syntax errors. Has anyone tried using asymmetric method? Will it be possible from the Duplicati UI in future?
I have successfully used asymmetric encryption as described above. You have to use these advanced settings in the last page of your backup configuration in duplicati
--gpg-encryption-command=--encrypt
--gpg-encryption-switches=--recipient "[email protected]"
--gpg-decryption-command=--decrypt
Also you got to have the trust level of your PGP Key set to level 5 (Ultimate) before otherwise it will not be accepted.
Additionally You need to correctly set the environment variable for your gnupg installation so that duplicati can find it. Set the PATH under environment variable in windows for your Gnupg installation e.g. C:\Program Files\GNU\GnuPG\pub
As Passphrase in duplicati on the first page of the backup configuration you need to use the passphrase of your PGP key and you got to specify PGP as your Encryption Method.
This way I have successfully used duplicati with PGP. Let me know if this doesnt work for you then I will try to help.
Oh perfect! Thanks a lot.. I successfully encrypted, verified that it was done using my private key and then successfully decrypted and restored as well. The thing I was missing was using my gpg passphrase on first page. Once again, thank you ! :)
Also to others who might not see the gpg configuration options in beta, I saw them once I switched to Canary version
Thanks for all the information here. Worked for me, though I had to point to the full file path of the GPG executable (C:\Program Files (x86)\GnuPG\bin\gpg.exe) for the parameter gpg-program-path (I used the GUI). @kenkendk: I haven't found any Wiki or FAQs for this. Happy to write some if you point me to the right place and the expected format for a setup guide!
@akyag: The encryption is done using your public key, not your private key. You should only need your private key to decrypt the backup.
For me the point of using GPG encryption vs. the inbuilt AES one would be to avoid storing the encryption passphrase on the server where Duplicati runs. Imagine the following scenario: Your server that runs Duplicati (which, for example, backs up from a network share of another server in a private network and regularly uploads the encrypted backup to Google Drive) gets compromised or stolen. The thief then extracts the auth token for your Google Drive folder and the passphrase from your Duplicati config to download and decrypt all your data very quickly and without you noticing this high-traffic activity. If you used GPG, she would additionally need to extract the private key of the encrypted key of gpg4win using the passphrase from the Duplicati config - that's just one more simple step, hence it's not more secure than using an AES passphrase with the in-built AES solution. To protect from this kind of attack, the private key should not be stored (and not even have been generated) on the Duplicati server. I'm currently testing my setup where I have generated a pub&priv keypair on another server and only imported the public key onto the machine running Duplicati. I'll post another message here if I run into problems restoring my files on a machine where I'll import the private key for test purposes.
@dEad0r do you have some experience to share? I'm very interested in such a setup.
do you maybe have a duplicati-cli command you use for this?
I currently cannot access my system to provide you the command.
What I can share is that I actually removed my private key from the server, and I was still able to recover files from the backups of that system (!!!). My conclusion was that duplicati isn't making proper use of the public key to encrypt the data.
I'll be happy to share my command once I get the chance to. Until then I'd say that the standard AES encryption option is the way to go.
Emil Lefherz [email protected] schrieb am Fr., 19. Okt. 2018, 12:39:
@dEad0r https://github.com/dEad0r do you have some experience to share? I'm very interested in such a setup.
do you maybe have a duplicati-cli command you use for this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/duplicati/duplicati/issues/2270#issuecomment-431321260, or mute the thread https://github.com/notifications/unsubscribe-auth/ADPWk-HHOFh7XAyzfBvLdFkTp9MJlx0kks5umavWgaJpZM4LpCpT .
I did not try to remove the private key yet, but I can definitely say that restoring the backup fails when you never had the private key on the machine at all.
I will test further and open a bug report if necessary
On 20.10.18 08:37, dEad0r wrote:
I currently cannot access my system to provide you the command.
What I can share is that I actually removed my private key from the server, and I was still able to recover files from the backups of that system (!!!). My conclusion was that duplicati isn't making proper use of the public key to encrypt the data.
I'll be happy to share my command once I get the chance to. Until then I'd say that the standard AES encryption option is the way to go.
Emil Lefherz [email protected] schrieb am Fr., 19. Okt. 2018, 12:39:
@dEad0r https://github.com/dEad0r do you have some experience to share? I'm very interested in such a setup.
do you maybe have a duplicati-cli command you use for this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub
https://github.com/duplicati/duplicati/issues/2270#issuecomment-431321260,
or mute the thread
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/duplicati/duplicati/issues/2270#issuecomment-431554427, or mute the thread https://github.com/notifications/unsubscribe-auth/AQelQAvRavGh3fIlFBNvS62MQTbsTaeIks5umsS2gaJpZM4LpCpT.
@dEad0r this time I tested removing the private key again, with gpg --delete-secret-key [email protected]. I could not reproduce your error, everything fine.
As Passphrase in duplicati on the first page of the backup configuration you need to use the passphrase of your PGP key and you got to specify PGP as your Encryption Method.
This does not make sense. In GPG, the passphrase is only used for the private key. The whole reason for asymmetric encryption is that the private key is not on the machine.
Why would duplicati save the password for the GPG key on the machine? They are just throwing one of the two factors away that way.
On the other hand, on the web interface I was unable to set the --passphrase=unused option which makes the cli command work. This means you have to set a passphrase.
I'm following this thread/issue with huge interest. My setup would be the following : use gpg asym for backup to local storage (i.e. same machine running duplicati) then synchronize the whole backup folder with another tool (synthing or rsync). I find here that nobody raises this thing that duplicati needs a way to decrypt not only to restore a backup but also to sample check the backup is OK. Hence duplicati needs access to the private key.
@bugith
...nobody raises this thing that duplicati needs a way to decrypt not only to restore a backup but also to sample check the backup is OK. Hence duplicati needs access to the private key.
Exactly. Which begs the question: is there any way to use Duplicati so that it doesn't have to rely on access to the remote (historical) backups? If not, then this whole thread about asymmetric encryption is meaningless. Using GPG offers zero advantage here.
W.r.t the scenario proposed by @dEad0r - the only mitigation I can think of is to prevent (disallow) deletion/modification of existing backup files by Duplicati. That way The Baddie™ will still have all your data, but will at least not be able to erase or corrupt your existing backups.
use Duplicati so that it doesn't have to rely on access to the remote (historical) backups?
I'm not following the GPG side here, but the remote is read back for restores and for backup sampling, and latter can be turned off. The backup itself will deduplicate blocks based on database records. Of course, if DB is lost, the source for rebuild is the remote files.
Thanks, that's good news. I also just found out that the answer(s) to my question are in https://github.com/duplicati/duplicati/issues/3074.
Just to add, the point of
- using asymmetric (public-key) encryption, and of
- making Duplicati work without it needing access to (its own) historic backups
... is that this enables a setup that prevents a would-be attacker from accessing said historic backups. So if a hacker gains unauthorized control over your machine, they'll have access to all current data and that's already bad, but it isn't made worse by him having access to all the old backup data as well. That kind of added security may be very valuable to some.
The fact that the existing backups on the remote server cannot be automatically compacted or validated is considered an acceptable tradeoff.
(BTW, "GPG" may be a source of confusion: the GPG software suite enables both symmetric and asymmetric encryption, for different use cases. Duplicati, by default, uses the symmetric mode; this thread and #3074 aims at the asymmetric mode.)
My use case is a bit different : my gpg key has no password (not such a weakness since the machine running duplicati is a desktop computer that can't be lost or stolen as easily as a laptop - even if it was, the key would be exposed, whatever AES or RSA/Ed25519 it is... and anyway, the data to backup are stored in this machine)
This issue has been mentioned on Duplicati. There might be relevant details there:
https://forum.duplicati.com/t/gpg-asymmetric-decryption-should-fail-but-does-not/17536/4
I currently cannot access my system to provide you the command. What I can share is that I actually removed my private key from the server, and I was still able to recover files from the backups of that system (!!!). My conclusion was that duplicati isn't making proper use of the public key to encrypt the data. I'll be happy to share my command once I get the chance to. Until then I'd say that the standard AES encryption option is the way to go. Emil Lefherz [email protected] schrieb am Fr., 19. Okt. 2018, 12:39: … @dEad0r https://github.com/dEad0r do you have some experience to share? I'm very interested in such a setup. do you maybe have a duplicati-cli command you use for this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2270 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ADPWk-HHOFh7XAyzfBvLdFkTp9MJlx0kks5umavWgaJpZM4LpCpT .
Hello @dEad0r , in my test I have the same result as you have. The logfile with loglevel "information" says, the secret key is missing, but the result is, the files have been restored, which should not happen. Your thread is old, but did you have new results, where GPG asymmetric is working correctly?
Best regards Martin
Sorry, I don't have access to my server any time soon to check. I remember that I may have chosen the wrong way to invoke PGP and it may have used symmetric encryption instead of asymmetric. I'm not sure if I ever properly set it up again and tested, but something tells me I did and at the end felt like there was no bug after all. Hope this helps in some way!
Regards
On Fri, Mar 15, 2024, 02:18 martindiscgolf @.***> wrote:
I currently cannot access my system to provide you the command. What I can share is that I actually removed my private key from the server, and I was still able to recover files from the backups of that system (!!!). My conclusion was that duplicati isn't making proper use of the public key to encrypt the data. I'll be happy to share my command once I get the chance to. Until then I'd say that the standard AES encryption option is the way to go. Emil Lefherz @.*** schrieb am Fr., 19. Okt. 2018, 12:39: … <#m_4469455059853678287_> @dEad0r https://github.com/dEad0r https://github.com/dEad0r do you have some experience to share? I'm very interested in such a setup. do you maybe have a duplicati-cli command you use for this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2270 (comment) https://github.com/duplicati/duplicati/issues/2270#issuecomment-431321260>, or mute the thread https://github.com/notifications/unsubscribe-auth/ADPWk-HHOFh7XAyzfBvLdFkTp9MJlx0kks5umavWgaJpZM4LpCpT .
Hello @dEad0r https://github.com/dEad0r , in my test I have the same result as you have. The logfile with loglevel "information" says, the secret key is missing, but the result is, the files have been restored, which should not happen. Your thread is old, but did you have new results, where GPG asymmetric is working correctly?
Best regards Martin
— Reply to this email directly, view it on GitHub https://github.com/duplicati/duplicati/issues/2270#issuecomment-1999241607, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZ5NE46YBSM3R5UIHHC4LTYYK4H5AVCNFSM4C5EFJJ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJZHEZDIMJWGA3Q . You are receiving this because you were mentioned.Message ID: @.***>
says, the secret key is missing, but the result is, the files have been restored, which should not happen.
I can restore with not just the secret key missing, but all Destination files missing, as it reads Source files. When testing, be careful you don't get tricked by any optimization. You can test with no-local-blocks on:
Duplicati will attempt to use data from source files to minimize the amount of downloaded data. Use this option to skip this optimization and only use remote data.
The logfile with loglevel "information"
Verbose gives a clear view of the sequential steps of the restore, e.g. it only reads destination as needed. There's not enough info to say exactly how user test got done, but I've been posting to the forum topic.
I'm still not a gpg expert, and I'm definitely not claiming that the implementation supports all use cases.
This issue has been mentioned on Duplicati. There might be relevant details there:
https://forum.duplicati.com/t/gpg-asymmetric-decryption-should-fail-but-does-not/17536/12