Re: [Duplicity-talk] PASSPHRASE, the environment, memory, etc.

[Charles Duffy]

Mark Rose wrote:
> You should look into ssh-agent. That would allow you to keep the private keys 
> on your local workstation.
>   
I'm pretty sure we're talking about GPG keys, not SSH keys. Similar 
concept, yes, and I think I've seen an implementation so targeted -- but 
not quite the same thing.
> Also, as a further note to the conversation, it's not a good idea to store the 
> private key with the data, as doing so allows an attacker to corrupt your 
> backup data, too. Storing it separately (say, on your local machine) prevents 
> that.
>   

Erm. We're using public-key crypto, yes? So the system creating the 
backups needs only the public key, and the system restoring them needs 
the private key.

Given that scenario, I don't see how separating off the private key 
stops fake versions of old backups from being created; what it does, 
rather, is preventing previous backups from being readable by the 
machine that made them. Granted, this stops subtler corruptions of old 
backups (as one can't decrypt the real copies to use the plaintext in 
creating fake ones) -- but I don't see that kind of threat model being a 
serious concern except in cases where one is backing up 
security-sensitive logs (such that an attacker may wish to cover his/her 
tracks through their destruction) -- and even in that case, an attacker 
can just as easily destroy the backups entirely rather than subtly 
corrupting them.

Now, if we want to prevent an attacker who has compromised the local 
machine from *reading* old backups -- valid point. An attacker intent on 
corrupting them, on the other hand, strikes me as a more unusual sort of 
threat model. (If we want to protect old backups from corruption, why 
not get someone else to act as a notary service and sign the hashes? 
That would strike me as the simplest approach).