New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPG asymmetric encryption module #2270
Comments
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 |
@kenkendk
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.
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. 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 |
You are very welcome. Glad I could help! |
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). @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. |
@dEad0r yes that's what I meant.. my bad |
@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 <notifications@github.com> 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>
.
|
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 ***@***.***> 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>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2270 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQelQAvRavGh3fIlFBNvS62MQTbsTaeIks5umsS2gaJpZM4LpCpT>.
|
@dEad0r this time I tested removing the private key again, with |
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 |
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. |
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. |
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 #3074. Just to add, the point of
... 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 has 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) |
It is currently possible to get GPG encryption working with a key, by setting the switches manually like this:
You also need to set the trust level of the key to 5, for example:
It would be nice if there was a module, say
gpg-pubkey
or similar that simply sets these options. Perhaps thepassphrase
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.
The text was updated successfully, but these errors were encountered: