duplicity-team team mailing list archive

[edso <question107216@xxxxxxxxxxxxxxxxxxxxx>]

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

edso posted a new comment:
>>
On smaller backup's I'd suggest going for fulls only, which never need a
private key, except for verifying/restoring.
<<

this was meant of course for older duplicity versions, which were not
able to do incremental backups without the private key.

>>
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.
<<

yes. I meant, if the hacker has come as far as having access to the
private key used, he pretty much has access to all data of the user the
backup job runs as. This means primarily: credentials and location of
the backed up data, passphrase for the private key used, the precious
data itself.

A clever hacker wouldn't probably steal 300GB, but

- try to put tempered data in the backup that looks trustworthy because
it was "securely" backed up
- shredder the whole system, but not without deleting the remote backed
up data first

Actually I spent some thought on security of the private key lately. It
is possible to use different keys for encrypting and signing. Encrypting
even supports multiple keys. Having said that I think the easiest/safest
route currently would be:

A dedicated key for the backup host (host key) plus your very own public
key. The backup would be encrypted to both public keys and signed with
the host private key.
The encryption to your own public key would act as a fallback in case
you manage to "loose" the host private key. This way you would still be
able decrypt your backup.
If you manage to loose the complete host key pair, this is also true,
but you loose the ability to verify that the backup is actually from
that machine.

In conclusion: I think duplicity only protects your backed up data from
manipulation and spying eyes. If you want protection from deletion or
silently injected bad data you probably will have to keep copies of old
chains somewhere not reachable/mentioned on the backup host.

regards ede


On 07.05.2010 00:00, Aaron Whitehouse wrote:
> 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.