Incremental backup requires GPG decryption key?

[davidchisnall]

Doing a full backup appears to work well with only the encryption key, but doing an incremental backup appears to need to be able to decrypt. I would like to be able to keep the decryption key off the machines being backed up so that if they're compromised the attacker can't read old backups. This could potentially be achieved by keeping a copy of the manifest locally and using the remote copy to verify the local versions by trying to re-encrypt the offline copy and see if it matches.

[someone1]

This may be related to #9 - Are you using the "smart" backup option? Both the local and remote copies of the manifests are signed and encrypted when the feature(s) are enabled, we keep a local copy of all manifests to avoid having to remotely pull them for every backup.

If you'd like to avoid needing the key for decryption at all - I think the manual backup option would be best suited here. I acknowledge I need to clean the code up and only ask for the key when required, something I keep meaning to get to!

[davidchisnall]

I'm not sure if this is smart - it was just an incremental backup: please back up everything from the last snapshot that was backed up, no deleting old backups or consolidating things. If it can see the names of the last snapshots from the names of the blobs, then it probably doesn't need the decryption key at all.

[someone1]

Sorry, just to clarify, for "Smart" backup options, I meant the --increment or --fullIfOlderThan options. You shouldn't need it if you specify the snapshot to increment from.

As zfsbackup-go is currently written, the blob names are mostly just a remnant from basing this off of how Duplicity worked, the actual trusted information is found within the manifests. It could be possible to start trusting the the blob names for bits of information though I opted against this as it was too inflexible.

Let me mull this over - I never intended the burden of helping users keep secrets on their system securely to be a part of this package though I'm open to small changes that could assist with this.

[davidchisnall]

Did you think more about this? Being able to use a separate PGP key pair for the metadata and the blobs would probably be sufficient. That would let you keep the metadata decryption key on the machine, but only the data encryption key. You could then do incremental backups, but anyone who steals your computer won't be able to decrypt your backups.

[someone1]

Sorry, its been a busy few months.

I like the idea of adding an optional PGP pair for the manifests, and I think it can be done without introducing a breaking change. I think I'll be doing a lot of cleanup/changes to the application this week and will try and get to this!