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

[Martin Pool]

>>> 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 don't know.  It looks like the manifest and sigtar files are cached
unencrypted on the origin.  Perhaps they're now no longer always hit
from cache (I think there are bugs where the cache misses
unnecessarily), or they're stored encrypted.  (This is another aspect
where you can't expect the backup contents to be secret from someone
who has broken into the origin server, though in this case they would
only get summary data.)

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

A machine reading from the backup needs to have the private encryption
key to read the contents, but it only needs the public signing key to
verify the signatures.  So this lets you have fewer copies of the
signature key and perhaps less chance signatures can be faked.  Also,
I suppose you might have multiple machines use different signing keys
but the same encryption key.  Also, it's just a capability that exists
in gpg so duplicity might as well expose it.

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

Oh, the backups originate on other machine or are of evanescent data?
But still, although locking this down is good, trying to keep data
secret from the machine on which it originates is ultimately unlikely
to really be secure.

m