|
From: | Dirk-Willem van Gulik |
Subject: | Re: [Duplicity-talk] remove-all-inc-of-but-n-full <num> and decryption |
Date: | Sun, 8 Nov 2015 19:13:35 +0100 |
On 08 Nov 2015, at 17:21, Kenneth Loafman <address@hidden> wrote:Could you explain "As I sort of need to give duplicity credentials that on sftp level already allow that environment to ‘corrupt’ my backups."? I seem to be dense today. So a nice property of duplicity is that it can (largely) operate with just a public key for backups. That means you can keep the corresponding private key ‘offline’ and only break into it during a restore. This significantly reduces the footprint & risks around backups. And makes a lot of threatmodel around remote servers & cloud/hosted situations simpler. Now obviously duplicity will need a fair bit of credentials on the servers it is backing up - at the very least enough to read (though not modify) the files & directories it is backing up. And it will need some credentials sufficient to ’sftp’ (or similar) to the storage systems that allow the creation & writing of files. In actual practice that means that in a lot of situations duplicity can also ‘corrupt’ its own backup. Because of a adversary has gotten sufficient control over it or its environment -or- because of a simple bug in the code. Hence allowing duplicity to delete (old) backups with just the public key is not that much of a weakening of the security situation; and will not change the risk- and threatmodel much, if at all. Does that help ? Dw |
[Prev in Thread] | Current Thread | [Next in Thread] |