Provide a way to use public key encryption

I'll point out that I'm not very excited about this. It's kind of a good way to shoot yourself in the foot, unless you backup your private key. So how are you going to back that up? If you already have a good backup for your key...

At best, maybe a secret gconf setting for it. But I'm not sure there is a use case for this.

A pgp secret key is pretty small and doesn't change over time. It can be
stored on a tiny flash media card, CD and safely stored on a remote
location. The good thing about it is that you only need the pub key to
encrypt and perform the backup. Restoring requires the sec key which is
fine (and has some consequences if you lose it!).
A good passphrase is supposedly hard to remember so that doesn't prevent
you for not losing the unlock key.

Michael Terry a écrit :
> I'll point out that I'm not very excited about this. It's kind of a
> good way to shoot yourself in the foot, unless you backup your private
> key. So how are you going to back that up? If you already have a good
> backup for your key...
>
> At best, maybe a secret gconf setting for it. But I'm not sure there is
> a use case for this.
>

Currently the system asks to store the password forever, store until you log out, or forget it immediately. I'm not interested in having my password sitting around so I ask that it forget it, however, this also means I can't take advantage of automated backups. If I could use my public key to encrypt I could store the private key elsewhere and this could truly be an automated system for my use case.

That's an interesting point, Will.

Useful option would also be to have keyfile instead of passphrase. You can store keyfile to a safe place...

Michael Terry >> if you think it's not safe to encrypt with only one public key, duplicity can accept multiple public keys (--encrypt-key key1 --encrypt-key key2 etc...like multiple recipients for email). If Key1 and Key2 are hold by two trustworthy persons located at two distincts places...
If you lost Key1, the Key2 will still be able to decrypt the data.

Regarding Comment #3, my understanding is that, if stored forever, this is encrypted in Gnome-Keyring with the user's login password rather than simply sitting around on the hard drive (though I have no idea what happens if you have it login automatically). I mainly point this out for any lurkers who come across the page.

Michael: I would be quite keen to encrypt to both a passphrase and my GPG key, as my GPG key may be destroyed, but I'm more likely to remember my passphrase for that if I still have a copy. Further, if you are looking for use-cases, it becomes a lot more sensible if you are talking about people with smartcards, which I understand are supported by duplicity.

Since PGP keys should be backed up on external media anyway, I believe it'd be great to be able to use gnupg encryption on the backups. In preferences, one could set a pgp key to encrypt with, and deja-dup would encrypt with that public key. Automated backups wouldn't require user interaction, or insecure password storage. I also believe that a pgp passphrase is more likely to be remembered than a backup password.

This would be rather trivial to implement if deja-dup allows passing custom arguments to duplicity.
After all, it's not DD is not "real" software - just a front-end to it. And it's so limited that I have to stick to command-line ATM.

Would like this feature for the reasons mentioned in #3.
It's good that the passphrase is stored in gnome-keyring as described by #7, but using public key would allow zero exposure of private encryption passwords while still supporting automated backups.

This would also provide a higher security workaround to https://bugs.launchpad.net/deja-dup/+bug/284512