diff options
Diffstat (limited to 'bugs/Support_encrypting_to_a_GPG_public_key_without_having_the_private_key.mdwn')
| -rw-r--r-- | bugs/Support_encrypting_to_a_GPG_public_key_without_having_the_private_key.mdwn | 55 |
1 files changed, 0 insertions, 55 deletions
diff --git a/bugs/Support_encrypting_to_a_GPG_public_key_without_having_the_private_key.mdwn b/bugs/Support_encrypting_to_a_GPG_public_key_without_having_the_private_key.mdwn deleted file mode 100644 index 2a62a70..0000000 --- a/bugs/Support_encrypting_to_a_GPG_public_key_without_having_the_private_key.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -[[!tag obnam-wishlist]] - -Normally, GPG can encrypt to a key using only the public key, without needing the private key available. I'd like to have the same model for obnam encrypted backups: perform a backup to a key using only the public key, without having the private key available. That way, I could perform backups of various systems using public keys whose corresponding private keys I keep entirely offline and secured. - ---- - -Unfortunately, Obnam requires the secret in order to do backups. It needs to download, and decrypt, -some metadata from the backup repository in order to add new backups there. See the [[obnam/ondisk]] -and [[obnam/encryption]] pages for details. --liw - ---- - -I've read those pages, but as far as I can tell, the ability to decrypt part of the repository doesn't seem like an inherent requirement to meet obnam's goals, just an implementation detail. And as far as I can tell, without some change in this area, obnam does not support letting a client perform backups without giving that client full access to previous backups. - -Use case: I want to back up to a storage system that I trust for availability but not for privacy; thus, I need encryption, and I can't do "pull" backups since I don't trust the storage server with access to the system that needs backing up. However, I also want the backups to protect me from security breaches, by giving me the ability to follow the standard advice for how to deal with a system break-in: nuke everything and restore from the last-known good backup. How can I have a "last-known good backup" if the backed-up system can access the old backups? - ---- - -I understand the desire to do what you want to do, but I haven't found a technical solution to do it. If you can -come up with one, then write it up and send me a pointer. --liw - ---- - -It'd be nice if Obnam could do this, but in the meantime, I think Duplicity can work this way. --AP - ---- - -If Obnam had a local metadata cache, could this be implemented? If Obnam had the metadata locally, could it do a quick verification that the metadata is the same as that on the remote repository, and then backup to the remote repository "blindly", using only the local cache as a guide? --AP - ---- - -A concrete existence proof: tarsnap does this. You can do tarsnap backups with only a restricted public key, and that key need not also provide access to decrypt old backups. -- Josh - ---- - -I've re-opened this bug since there's ongoing discussion. I'll have a think and respond later. --liw - ---- - -Having thought about this... - -* Obnam will probably eventually get a local cache for stuff from the repository. - However, this is not enough: we can't assume the cache is complete, since - other clients will be making changes to the repository as well. -* Obnam will thus need to read, and decrypt, files from the repository. -* Having access to the PGP private key is thus necessary for Obnam. - -I haven't looked at how duplicity and tarsnap do things. If someone comes up -with a design for Obnam that can do this, without sacrificing things such as -de-duplication across clients, please e-mail the Obnam mailing list with -suggestions. Thanks! - ---liw - -[[done]] |