← Back to team overview

duplicity-team team mailing list archive

Re: [Question #107216]: Public key encryption and incremental backups

 

Question #107216 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/107216

    Status: Answered => Solved

Aaron Whitehouse confirmed that the question is solved:
Thanks ede

Note that this is actually addressed in the man page (a classic case of RTFM, sorry):
http://duplicity.nongnu.org/duplicity.1.html
===
--encrypt-key key 
When backing up, encrypt to the given public key, instead of using symmetric (traditional) encryption. Can be specified multiple times. 

To save bandwidth, duplicity generates full signature sets and
incremental signature sets. A full signature set is generated for each
full backup, and an incremental one for each incremental backup. These
start with duplicity-full-signatures and duplicity-new-signatures
respectively. These signatures will be stored both locally and remotely.
The remote signatures will be encrypted if encryption is enabled. The
local signatures will not be encrypted and stored in the archive dir
(see --archive-dir ).

The archive directory should not be deleted, or duplicity will have to recreate it from the remote repository (which may require decrypting the backup contents). 
===

So, as ede says, this should all work correctly unless the local
(decrypted) copy of the signatures are deleted.

> But what good is your backup anyway if the hacker has access to your private key, he has 
> access to the duplicity backend credentials as well as to the data itself.

I'm sorry, I'm not sure what this means. Using public key encryption is
in a lot of ways more sensible for unattended backups, as passphrase
(symmetric) encryption requires that the unattended script have access
to the cleartext passphrase. The only (and significant) downside to
public key encryption for backups is that the key needs to be backed up
somewhere manually for the backup to be any use. I understand that this
is why déjà-dup does not have the option enabled.

I'm guessing that you are saying that storing a cleartext passphrase
isn't a big deal, as if the "hacker" could get to that, they could get
to the files themselves, which is probably true. Arguably, it would be a
lot easier to get a copy of/sniff a single phrase without my knowledge
than copy 300GB of data (assuming the hacker had access to the
ciphertext of the backup), but there isn't a lot in it. In my case, I'm
backing up a number of machines, some of which I trust less than others.
I don't really want to have different passphrases for each and I don't
want my valuable passphrases in cleartext on some of these machines.
Encrypting to my public key means that I only need to put my public key
on untrusted machines (no security risk), but does mean I have to keep
backups of my private key outside of Duplicity.

-- 
You received this question notification because you are a member of
duplicity-team, which is an answer contact for Duplicity.