Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm setting up automated backups with duplicity, but there's something I don't get. I have imported my own public GPG key, but it seems that duplicity wants the private key as well. It was my understanding that the public key was used to encrypt the data, and the private key to decrypt it. Therefore, I see no reason why the private key would be needed here.

Please enlighten me :)

share|improve this question

migrated from Sep 10 '11 at 15:34

This question came from our site for professional and enthusiast programmers.

I don't know duplicity, but probably it's needed to sign the backups. What options are you using? – Matteo Italia Sep 10 '11 at 14:26
If you're worried about security, why not make a second key-pair and give it that private key - as long as you remember which public key to use to get the backups again, that should work? – deanWombourne Sep 10 '11 at 14:28
@Matteo: You're right, it's because it's trying to sign the data. That's too bad I can't mark your comment as accepted! deanWombourne: Yes, I guess it would work too. – Executifs Sep 10 '11 at 14:31
@Executifs: well, this can be quickly fixed. :) – Matteo Italia Sep 10 '11 at 14:37
up vote 4 down vote accepted

I don't know duplicity, but probably it's needed to sign the backups.

share|improve this answer
Could you elaborate on why signing would be needed? – Simon Sheehan Sep 10 '11 at 15:38
If you mean "why would you need signing", it's to make sure that nobody modified the backup after the signature. If it's "why do you need a private key for signing", it's because you use it to encrypt the hash, so that everybody can check it (decrypting it with the public key) but nobody can recreate it after tampering the data. – Matteo Italia Sep 10 '11 at 15:55

Duplicity doesn't sign the archive unless you specify --sign-key key-id option. In non-signing mode (only performing the encryption) the private key is needed only for the real decrypt/restore, and, let's say, archive read actions, which require re-syncing the archive with the local cache (=decrypting the archive).

In the past years this feature was changed heavily. But I can say we are automatizing it a lot without the need of private key. The biggest mistake we have been doing in the past was inconsistent directory specification, look:

  • the cache name for a particular target_url, like file:///usr/local/backup is a hash of that string
  • we have accidentally generated a slightly different url aiming the same target, like file:///usr/local/backup/ (with trailing slash) or file:///usr/local/./backup for the read actions (collection-status, list-current-files, etc)
  • when the url differs, the hash also differs and such cache doesn't exist (or is in an inconsistent state)
  • this action must create a new cache and therefore needs the private key in order to decrypt the archive
share|improve this answer

Cloud be. But there you can create an extra signing key to keep the private key which encrypted the backup very save: The Problem is here:

share|improve this answer
Please elaborate on what's found within the post, instead of just pasting a link to it. – KronoS Aug 9 '13 at 21:44

You must log in to answer this question.

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