1

I'm struggling to have a working and robust configuration for my backups using Duplicity, knowing that I want asymemtric GPG encryption based on key pairs. And to be able to backup securely from multiple devices.

What I have today :

I have succesfully sent encrypted data to the remote storage and restored the backed up files from it.

Now, I have 2 issues with this setup :

  1. I have to enter the key passphrase on each backup operation

I suspect it is the case because my sign key is password protected (the same password is used to protect all subkeys, which is a GPG limitation AFAIK) I tried to setup the gpg agent and to store the password in the cache for an unlimited amount of time. Which doesn't work and isn't maybe a wise thing to do anyway. That limitation makes it really hard / impossible to setup unattended backups

-> should I use a sign subkey that is not password protected ? It does not seem to be the right thing to do either ...

  1. I want to backup from multiple devices

With my current setup, I would need to import the same set of keys to a new device. Which obviously I want to avoid. If a device is compromised I don't want all my backups to be accessible to an attacker that could decrypt all the data with the stolen keys. -> "don't put your eggs in the same basket".

To begin with, "don't put your eggs in the same basket" could also be taken to mean that you shouldn't rely on your one PGP keypair for everything. For example, you should create a "backup/storage" keypair separate from your "email/Git" keypair. After all, they have completely different usage and requirements – your backups are completely internal so they do not benefit from being signed by your "main" PGP keypair anyway.

=> That makes sense thank you, Creating a new backup specific keypair seems reasonnable.

But also, if I understand the system correctly, Duplicity doesn't need to be able to decrypt your backups – it only needs to encrypt them. (Unless you need to restore, of course.) That should mean you don't actually need the private part of the encryption subkey on any of the devices that contribute to the backup repository, it only needs to be present at restore time.

=> I think you are correct. Except maybe for the case where an incremental backup failed and needs to be re-started, as this situation should not happen that often, a manual intervention is acceptable I guess. All this to say that, yes, the private subkey for encryption may not be on any of the devices.

-> What would be a recommended strategy here ? From what I understand today it is not doable to manage multiple encryption / sign subkeys with the same GPG master key ? Should I generate multiple master keys for backup purposes ?

I'll try to sum up :

  • if I want a different encryption key per device (seems to be the safest option), I have to have a generate a new keypair for each device right ?
  • as for the signing key I'm still confused on how to proceed...
    • should it be managed as a subkey of the device specific keypair ?
    • or one single key for all devices ?
    • multiple signing keys as subkeys of a separate keypair ?

Does that makes sense ? Again, thanks for your help !

Improve this question

1 Answer 1

Reset to default
0

I want to backup from multiple devices

With my current setup, I would need to import the same set of keys to a new device. Which obviously I want to avoid. If a device is compromised I don't want all my backups to be accessible to an attacker that could decrypt all the data with the stolen keys. -> "don't put your eggs in the same basket".

To begin with, "don't put your eggs in the same basket" could also be taken to mean that you shouldn't rely on your one PGP keypair for everything. For example, you should create a "backup/storage" keypair separate from your "email/Git" keypair. After all, they have completely different usage and requirements – your backups are completely internal so they do not benefit from being signed by your "main" PGP keypair anyway.

But also, if I understand the system correctly, Duplicity doesn't need to be able to decrypt your backups – it only needs to encrypt them. (Unless you need to restore, of course.) That should mean you don't actually need the private part of the encryption subkey on any of the devices that contribute to the backup repository, it only needs to be present at restore time.

From what I understand today it is not doable to manage multiple encryption / sign subkeys with the same GPG master key ?

You cannot have multiple encryption subkeys (as the sender cannot know which device you'll want to read messages on, so the only working option is to encrypt to all of your encryption subkeys – which rather defeats the point of having multiple).

On the other hand, you can easily have multiple signing subkeys per key, as it's the opposite situation from encryption.

(the same password is used to protect all subkeys, which is a GPG limitation AFAIK)

It's more likely an UI choice. The gpg-agent does support different protection for each private key (it doesn't actually care about the relationship), but if the GnuPG UI were to make the "change password" operation affect only the specific subkey, it would likely confuse more users than it would help.

Find the "keygrip" of each private key from gpg -K --with-keygrip, then use gpg-connect-agent to change its passphrase directly (bypassing GnuPG):

gpg-connect-agent "passwd KEYGRIP" /bye
Improve this answer
1
  • Hi @user1686 First, happy new year, best wishes :) For some reason I wasn't notified about your reply, apologies for the late comment. I edited your answer to include a few questions, as the only way I saw to format it properly, but feel free to edit it anyway you like.
    – Spiroid
    Commented Jan 10, 2022 at 0:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .