This issue should collect use cases for asymmetric backups. In this situation, restic is able to efficiently create new backups, but unable to decrypt/restore and/or modify old backups. Please add your use case to this issue if you have one. I think we have enough use cases, thanks!

Summary (2018-04-28)

At the moment, restic (mostly) interacts with "dumb" storage (local, s3, b2, gcs, azure, everything except for the REST server with --append-only). restic can save, list, get and delete data in a backend. This is required for a backup, so the needed credentials to access the backend need to be present. On the upside, restic can use almost any storage, there are very few restrictions. On the downside, once attackers gain access to a server, they can easily extract the credentials for accessing the backend and the restic password, giving them all possibilities: Decrypt historical data from the repository, modify data, delete the whole repository.

When we add asymmetric cryptography, the only difference for attackers in such a situation is that they cannot decrypt historical data from the repository. Everything else, especially deleting all the data, is still possible. So "just add asymmetric crypto" is not the whole story.

The other idea is to not access the "dumb" storage directly, but indirectly via a custom server implementation. We've played around with this idea and added the --append-only option for the REST server, which can be seen as an "adapter" to access the "dumb" storage at the local harddisk.

The only exception from the first paragraph of this summary, and an implementation of the "adapter", is the rclone backend: It can be accessed e.g. via SSH (restic -o rclone.program='ssh user@server', with a hard-coded call to rclone via ForceCommand in .ssh/authorized_keys for the SSH key the user logs in). The cloud access credentials reside on the server, the user and machine running restic won't have access to those. If --append-only is specified in the call to rclone, data can only be added.

Having "non-dumb" storage alone won't help against attackers reading data from the repository (at least not without changing the repo format), but will prevent deleting all data in the repo.

So, in conclusion, to defend best against attackers taking over a server that uses restic for backups, I think we would need to implement both (non-dumb storage and asymmetric crypto). That's a long-term goal :)