duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

On 19.06.2014 10:00, Radomir Cernoch wrote:
> Dear all,
> 
> I would like to use duplicity (v0.6.23 from Debian) without saving the
> private key or its passphrase on the computer. After having abandoned
> signing and started using encryption only, there is still an issue.
> 
SNIP

it sounds reasonable at first that you might want to keep only the public key portion for encryption on your backup machine for security reasons.

what's the gain? imagine the following:
an attacker has already got physical access to your site, all your data in at least this account, the data you backup to somewhere incl. your private key to encrypt it.
without the private key the attacker still has all the above, just minus the ability to decrypt your backups and look into the past of your data. 
from my point of view that is simply not worth to risk corrupted backups. but that is essentially consequence if you want to do incremental asymmetrical encrypted backups.

here's why: 

1st issue

duplicity does incremental backups to potentially insecure sites, hence the encryption. this means that it needs either
- access to the encrypted data to determine the backup source's changes against
 or
- an up to date local cache (archive-dir) to do the same

as the metadata is saved in two different locations (remote,local archive-dir) there is a potential possibility that they run out of sync. if this happens and they are not synced before duplicity starts the following incremental will contain wrong incremental changes against the previous backup hence rendering the backup data corrupt.

2nd issue

you cannot run verify on your backups, which is strongly suggested to do periodically to ensure that your backups are still healthy. corrupted backups can occur due to
- remote site failure (transfer errors, fs corruption, bit flips, hacks)
- faulty duplicity algorithms (restarting actually created faulty backups just recently)
- you name more..


here comes the solution:

create key pairs on a per machine basis. encrypt against them _and_ your personal public key. keep the machine secret key to let local duplicity decrypt your remote backups. this way even if the machine key got lost you can always decrypt your backup.


the future:

we talked about checksum based circumvention of the need to decrypt the remote site. 
 https://bugs.launchpad.net/duplicity/+bug/687295
but that's only talk until today, nobody took the topic forward or implemented any of it.


hope this helped ..ede/duply.net