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. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
