Re: [Duplicity-talk] encryption keys, signing keys, PASSPHRASE, and gpg-agent

[edgar . soldin]

On 10.09.2011 05:53, Joey Morin wrote:
> greetings listers,
> 
> i've looked in the archive, and haven't found a discussion that covers my 
> question.  chances are that i've just overlooked it, so apologies to whoever 
> points me in the right direction...
> 
> i've been using duplicity for almost two years now, and have been using 
> symmetric encryption, as is the default.
> 
> i've recently become interested in using gpg to generate keys for asymmetric 
> encryption and signing. i'm intrigued also about the idea of using separate 
> keys for each.  i'm curious about what the right way to do it might be.
> 
> i understand that it's important to protect gpg generated keys with a 
> (strong) passphrase.  however, using passphrases presents a problem for 
> unattended backups.  i know that it is possible to set the environment 
> variable PASSPHRASE before calling duplicity (in fact, the wrapper script 
> i've been using does exactly that for symmetric encryption, and then unsets 
> the variable afterwards).  however, this still requires the passphrase be 
> accessible beforehand, and in plaintext.  my current script runs as root and 
> sets PASSPHRASE based on the contents of a plaintext file.  the file has mode 
> 000, but that doesn't seem to be safe enough.  mode 000 plaintext is no 
> barrier to a root-compromised machine.
> 
> the use of passphrase-protected asymmetric keys would not seem to mitigate 
> this limitation.
> 
> i realize that unless the keys and passphrases escape, the only way plaintext 
> storage of passphrases could be a problem is if the machine doing the backups 
> is compromised in the first place, in which case the data being backed up 
> would already be exposed (let's set aside for the moment the exposure of all 
> the historical backup sets compromised by a leaked key).  however, since 
> backups are for (among other reasons) disaster recovery, it's important to 
> safely store the keys in another location, increasing the risk that the keys 
> might escape.  this would seem to re-enforce the importance of strong 
> passphrases.  but then, the passphrases should also be stored in another 
> location.  after all, i could get hit by a bus tomorrow, and then how would 
> my successor get at the backup of that important file that our favourite user 
> just accidentally deleted?  so what's the point of a passphrase-protected 
> key?  isn't it just a weak key locking up a strong key?
> 
> so it seems i have a few choices:
> 
>  1. continue to use symmetric encryption with a locally stored passphrase for 
> unattended backups.
>  2. use asymmetric keys with no passphrases.
>  3. use passphrase-protected asymmetric keys, but store passphrases locally 
> for unattended backups.
>  4. use gpg-agent or some other mechanism to manage keys and passphrases in 
> opaque but fully unattended and fault-tolerant manner

you pretty much summed all the alternatives up here. the only other one is 
currently not stable and safe with duplicity. it is planned to support it but 
no kind soul did finish it so far.

5. unattended backup without a secret encryption key
 
> this is where i fall down.  i don't know how to make 4) happen.  

use a patched gpg-agent. patched because gpg-agent secrets time out after a 
period. there is no way to keep them in memory indefinitely like ssh-agent 
does. that's the state of knowledge i currently possess, while i don't know 
where to get a patched version, you probably have to do it yourself.

>i'm also unclear as to how this can fully mitigate the risks associated with 
>1) through 3) while maintaining fully unattended operation.  

sorry what do you mean? 4. as the only alternative does it perfectly because 5. 
currently is not reliable.


ede/duply.net