Public key encryption support

[KenMacD]

Storing the key used to encrypt backups on the server used to create the backups is not ideal. It's impossible to tell when it's been stolen, and stealing the key once would provide access to all past and future backup data.

Instead it would be nice if a new symmetric key was somehow for each archive, and then encrypted using the public key. That way the private key could be kept safely offline until a restore was required.

Duplicity does something similar in using gpg to protect the files.

[jungle-boogie]

How would automated backups work?

[KenMacD]

I would hope the same as they currently do, just without the requirement to have the private key material on the server. The public key can exist on all the servers, but with it the data could not be decrypted.

I'm not currently sure what data needs decrypting during future backups, so I'm not sure if this is possible, but it seems like as long as the metadata is available the actual data may not need to be.

[ThomasWaldmann]

The problem here is that the code (as is) uses the repository mostly as a key/value store.
The repo manifest (has the list of all archives) is stored at key=0.
When a new archive is created, the manifest is read, the new archive entry is added and the manifest is written back. That does not work if the encryption is not reversible for the client.

[KenMacD]

Would there be any way to keep the manifest/metadata using a symmetric key, but encrypt the data with a public key?

[ThomasWaldmann]

of course one could always specialcase the manifest.

but that was just an example, there are also other chunks that need to get read (and not just written), e.g. for delete / prune. this might be a feature rather than a problem though because if you do not fully trust the client, you maybe do not want that prune / delete works from there.

compaction is also a place where stuff gets read and re-written, it has to be checked - maybe no decryption is needed in this case.

[KenMacD]

Thanks for the info. So if I'm understanding this correctly it may not be impossible, but is certainly not easy or likely to happen any time soon. Is that about right? Is so feel to close this wontfix.

[RonnyPfannschmidt]

How about having a "extend" Operation to add to the manifest,

then knowing the content is no longer needed to add New archives

[thomsh]

KenMacD is right,
Encryption on a public key must be the law, you can rely on GnuPG.
I cant imagine a backup job with a static passphrase on the server.
:(
Other feature are great!

[enkore]

Crypto roadmap -> #1044 Currently PK is not on it, but technically possible by the draft DEK spec.

We really need this feature! Passwords for critical data is not serious...

[enkore]

Stapling #120

[rugk]

As stated in #1786 you may also use gpg for signing these backups if you implemented it.

In any case I think that a kind of hybrid encryption would be nice as it combines the advantages of both encryption methods.

• Encrypt (& possibly sign) a symmetric key/secret (maybe the one you currently use, so that one can still use a password in addition) with a pgp public key
• Store the encrypted result (and maybe the pgp key) on the server
• When one wants to create backups one needs to decrypt the secret stored on the server with the private key (& if used - the password) and then data can just be encrypted in the way it is currently done.
• Maybe - which would be harder to implement, but may be a future goal - you can implement an automated "key rollover" where old symmetric secrets are thrown away and new ones are generated and encrypted with the same public key. This would then also provide forward secrecy.

This would be good as:

• you would only use (slow) asymmetric encryption for a small secret instead of all files
• so fast symmetric encryption is used for the actual encryption process
• you can keep the current encryption model and build the asymmetric encryption around it
• the secret can be signed, thus providing integrity
• even if the asymmetric encryption is broken (yeah, quantum computers looking here¹) one could not decrypt the actual data - if the user still uses a password as currently done
• it's a kind of "two factor authentication" (one thing you need to know: your password; one thing you need to have [on your computer]: the key pair)

In any case I'd argue:

• to still provide the current model with a symmetric encryption (where the password is needed) and to
• only use asymmetric encryption to build this "around" the symmetric core

¹ Note that current symmetric encryption is considered secure against post-quantum attacks.

[enkore]

Signing archives and using asymmetric key derivation to encrypt archives are imho different topics.

Signing is relatively simple to bolt-on externally (or internally), by signing the tip of the hash tree, ie. the archive ID. This is pretty much what git and other software does (do git cat-file -p <signed commit>), but rather expensive to actually verify (not just verifying that it's a correct signature for the archive ID).