Support asymmetric backups
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](https://github.com/r
Posted by fd0 on May 14, 2015, 8:26 AM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.7,000 issues0 comments
support (Sysadmin)
Support connecting to remote devcontainers (devcontainer on remote host)
Option to use Waffle menu or links displayed normally
I also attempted to package ROCM on musl.
But why is there no such pushback agains linux kernel?
OpenCode Support
Upcoming changes to the tado° API
Allow Mac users to use Apple native containerization
Support for the Containerization Framework on macOS
Support asymmetric backups
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](https://github.com/r
Comments (0)
No comments yet. Start the discussion.