duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: edgar . soldin
Subject: Re: [Duplicity-talk] Why 'duplicity without private key' is a bad idea - WAS: Restart duplicity without private key
Date: Thu, 19 Jun 2014 15:07:25 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 19.06.2014 14:22, Radomir Cernoch wrote:
> 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.

that's insecure by design

> 2) Ensure that a successful attacker, who compromises a single machine,
> does not have access to data on all other machines.

see point above

> 
> Your solution indeed solves both issues. However, there is a price to
> pay: Twice the storage and twice the processor time for encrypting.

don't understand, why? you mean key creation?

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

no, duplicity creates tarlike volumes and signatures and manifest and pipes 
them through gpg. you can either encrypt against multiple keys or one 
passphrase.

duplicity already only downloads metadata for archive-dir sync to be bandwidth 
efficient as opposed to the whole last backup to determine the changes.

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

no! we use gpg which does either one only. as a side note, you can however sign 
symmetric backups within limits. see
 http://duplicity.nongnu.org/duplicity.1.html#sect20

..ede/duply.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]