Hi there. First time user of restic. On the documentation about encryption, they talk about the possibility of having multiple keys. But the point of multiple keys is not clear for me. So I ask the following questions that I think they could be added to the documentation for others to see:
When I run a command like “snapshots” (to see the snapshots), restic asks for a password. I set up two keys (whatever that means) before this and it seems I can fill any of these two passwords that the output is the same, it lists passwords for both hosts. Does this mean that regardless of what key is used, the content of the different hosts that use different keys gets encrypted in the same way?
Say if two people who don’t trust eachother and both what their stuff in the same repo. Would them using their own keys keep them safe from eachother or not? If they had identical documents, would they not be duplicated?
All repos have a second key. This second key is my master key.
I can work with all repos from my home-computer using only the master-key.
It is easier for me to have only one key to work with all repos → simpler setup. It also helps during recovery. I don’t need to search for a machine-specific key.
People having access to one key can only have access to the one repo it belongs to, not to any other repos. So it isn’t as privileged as the master key.
Every key in a restic repository has the same access. That is every user can read everything in the repository. Why should two users which don’t trust each other use the same repository? There’s a lot that could go wrong in that case and it get’s far more complex if deduplication should work between users who cannot read each others files.
Why should two users which don’t trust each other use the same repository?
Got it. they are not supposed to. Because regardless of the number of keys related to a repo, the repo always encrypts the data with the same unique-for-that-repo master key. Correct?
I want to add that even if multiple machines/people backup to one common repository with individual keys (might make sense for deduplication to be more effective), you could remove a key if you want to lock out a machine/person, e.g. if a member leaves a team.
Because regardless of the number of keys related to a repo, the repo always encrypts the data with the same unique-for-that-repo master key. Correct?
Exactly, and if they didn’t use the same repo-master key, deduplication would not work, so just as good to just split up into separate repos
… you could remove a key if you want to lock out a machine/person, e.g. if a member leaves a team.
You could, but it would have been easy for them to grab a copy while they still had access, so it is probably not good to rely on that approach to prevent future access to the repo.
But isn’t it always like that? I mean, it’s the same with Fileservers, vpn accounts and so on. If I fire an employee, I will remove hin from Fileserver access. Of course, maybe he already copied everything but still it makes sense to remove him. Same with repo keys.
It is true that if the user had access to the repo (key+data) they could have copied everything that was in the repository at the time the person was let go.
However, if your strategy for removing access relies on removing the key from the repo, it seems to imply that the former employee may still have access to the repo. With his key copy, they can access not only what was in the repo at the time they left, but anything that gets put in the repo in the future.
So, basically:
If you can remove any access by the former employee to the repo location, then it doesn’t matter if you remove the key.
If the idea is to prevent the former employee from reading what gets put in the repo in the future, under the assumption that the employee may be able to gain access to the repo after leaving, then removing the repo key is useless. What you would need to do is to create a brand new repo with a new master key, and then add new keys for the remaining employees to that.
If it looks like you are implementing a situation where this could arise, you should probably have separate repos for each user in the first place. The security implications would seem to far outweigh the potential space saving benefits.
And btw: you can keep users from ever downloading anything from the repo by using rest-server as a storage interface and setting it to append-only mode.
Wow this is awkward. Thanks for pointing that out! I haven’t been using it like that and so never tested it but somehow always assumed that to be the case.
You can reserve one key for emergency. You don’t use often, it so as not to expose it. You may reuse this password elsewhere (though still it’s better not to reuse passwords as much as possible).
For daily use, you use a second random password. You can save this on disk with 600 permission. If this password leaks, the other “backdoor password,” and thus other data protected with that, is secure.