Re: [Duplicity-talk] Restore has trouble with multiple encryption keys

[edgar . soldin]

Ezra,

the same tip using gpg-agent applies to async key encryption. main advantage in 
using the agent is that it caches th epassphrases in memory so you only have to 
give them once.

..ede/duply.net

On 20.01.2016 22:52, Ezra Stevens wrote:
> Edgar,
> 
> To clarify, I am using asymmetric encryption in real life, with
> passphrases on the private keys - my example used symmetric encryption
> to keep things simple, and the same issue results either way. But yes,
> I wrote "key" when I meant "passphrase" in my original message; sorry
> for any confusion.
> 
> I was thinking that Duplicity could determine which chain to restore
> by looking at the timestamps that are written into the filenames, but
> if those aren't getting parsed already then I don't imagine you'd want
> to add that layer of complexity. Anyway, switching up my backend
> folders when I rotate keys shouldn't be too difficult. Thank you for
> the swift response!
> 
> Ezra
> 
> 
> On Wed, Jan 20, 2016 at 2:57 AM,  <address@hidden> wrote:
>> On 20.01.2016 00:46, Ezra Stevens wrote:
>>> Hi folks,
>>
>> hey Ezra,
>>
>>> I'd like to be able to rotate my encryption keys occasionally when
>>> using Duplicity (between backup chains only, not in the middle of a
>>> chain). This works fine when I restore to the same machine I backed up
>>> from, but not for restores to a different machine. Specifically, the
>>> restore will fail repeatedly as it tries to synchronize the cache,
>>> because it keeps trying to sync files that it can't decrypt with the
>>> key it's been given.
>>
>> your diagnosis seems correct. be aware that there is a difference between a 
>> gpg key and a gpg passphrase for symmetric encryption, which is what you are 
>> using.
>>
>>> But if I give it different keys enough times, it
>>> will eventually sync the whole cache and then be able to restore
>>
>> that's the current design - keeping unencrypted metadata about your remote 
>> backups to minimize traffic and allow resuming in case of errors.
>>
>>> properly (see shell transcript below). Is this a bug, or is what I'm
>>> trying to do completely unsupported?
>>
>> in a way.. there is no way to feed more than one passphrase to gpg on the 
>> command line and as nobody considered your use case before (obviously), 
>> there are no routines to try a second , if the first fails.
>>
>>> Is there a way to convince
>>> Duplicity to only sync the cache files for the chain it's actually
>>> trying to restore?
>>
>> nope, it always sync all chains. note, you might want to restore from a 
>> specific time. how would duplicity find that if it didn't parse all chains 
>> first?
>>
>>> Should Duplicity print a warning when a user tries
>>> to use different encryption keys within the same bucket?
>>
>> don't think so. usually duplicity is run automatically via scripts and not 
>> by hand, so this is a corner case. also, duplicity should already err out 
>> during resuming an interrupted backup if the pass/key differs. but that is 
>> probably the only time that is implemented.
>>
>> finally - what you can try:
>>
>> 1. use gpg-agent for the restores. it will allow to enter several 
>> passphrases during a gpg call.
>>
>> 2. simply switch backend folders/buckets when switching passphrases
>>
>> ..ede/duply.net
>>