Re: [Duplicity-talk] Asymmetric backups broken in 0.6.15?

[Dan Loewenherz]

On Fri, Sep 2, 2011 at 1:01 AM, Martin Pool <address@hidden> wrote:
>> In any case, it is not possible for me to have my encryption passphrase on 
>> plain text on the server
>
> It sounds like you're trying to have the backup source machine able to
> write encrypted data but not read it back.  I don't know if this is
> going to work in duplicity because the source machine needs to be able
> to read the previous increments to work out what it's going to send
> and to calculate the deltas.  So even if you're using an asymmetric
> encryption key, it needs both the public and private halves as far as
> I know.

The point I am primarily making in my email was that I was able to do
this on version 0.6.14, but now I am not. On servers I set up a couple
months back, backups are working perfectly for me with asymmetric
encryption AND only a public encryption key. What changed in the most
recent version that broke this functionality?

I also wonder what the point of using separate signing and encryption
keys if passphrases and private keys are all readable on the server?
Why not just have one key for signing and encryption and forget about
all this extra complexity if it doesn't add to security?

>> Having my encryption passphrase in plain text on the server compromises my 
>> backups if the encryption key is somehow leaked.
>
> Well, specifically it means that if someone breaks into the source
> server, they'll be able to read all the backed-up history of that
> server.  That's not great, but to me it's only slightly bad because
> they can already directly read all the current contents of the files
> off the source server, and mess with it in other ways.

Good point. So what's the purpose of splitting up the encryption and
signature keys?

>
> Note that there's no need to have the keys on the machine holding the
> backups and breaking in there shouldn't let them read anything (though
> perhaps they can delete or damage your backups.)

I delete the backup after they are uploaded by duplicity, so this is
not a big issue. Additionally I have S3 permissions set that only
allow the duplicity credentials to create new keys (e.g. no delete
permission is given).

Dan