[Duplicity-talk] Why 'duplicity without private key' is a bad idea - WAS: Restart duplicity without private key

[edgar . soldin]

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