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

[Radomir Cernoch]

OK, I see your point. I had 2 motivations for the "without private key":
1) Backup several machines with a single key pair for easier management.
2) Ensure that a successful attacker, who compromises a single machine,
does not have access to data on all other machines.

Your solution indeed solves both issues. However, there is a price to
pay: Twice the storage and twice the processor time for encrypting.
In my case, the storage is not a huge issue, but the computation
resources are.

Then I thought that the "per-machine key pair" is only needed to
decrypt the meta-data, which is significantly smaller than actual data.
Can duplicity use an encryption key for meta-data only?

And would it be possible to combine an encryption-only public key and a
symmetric-key? I'm asking, because from a "BASH-script point of view",
an AES passphrase is easier to generate than a GPG key pair.

Thanks,
Radek

Thu, 19 Jun 2014 13:17:20 +0200 address@hidden:

> 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
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk