Hi,
I am new to restic and find it very interesting. I have noticed the “–append-only” option on the rest-server, and some discussions about key security. This make me wonder if append-only mode could be implemented at the password/key level : add the ability to create a “append-only” key for a repository, which could be more safely distributed than the master key.
Sorry if this has already been discussed
This is not possible for various reasons.
The REST-server just manages files for the restic client, over the REST protocol. It is not something that manages the keys. And you can’t create such keys on the client to satisfy your suggestion, since a compromized client can do whatever it wants anyway. The REST-server doesn’t see the actual contents of the repository, it just sees encrypted files being thrown at it for storage.
Thanks for your answer. In the scenario I was thinking of, the compromised client would only have the “append only” key, so it would prevent the attacker to alter the remote backup, even in the case where the rest server is not used (such as sftp). The “master” key would be only used for repository management and could be stored elsewhere.
Yes, and that cannot be done without a backend/server that is more involved with the unlocking of the repository than REST-server (and any other backend for restic) is.
Repository management makes little sense on the client anyway. Just let the client store data via (append-only) REST and then forget/prune locally on the backup server.
You might also consider keeping the repo key on the server only and kick off the backup via ssh from the server passing the repo key with the backup command only.
The fact that restic supports multiple “keys” is a bit irritating from a security point of view. In fact it always uses a single key - the master key - to do all encryption. This also means, that if a client knows one “key”, it is able to derive and save the master key having always full access to the complete repository.
The multiple “keys” are in fact multiple passwords which all allow to derive the master key.
Thanks for the clarification, @alexweiss ! But in the scenario above, the key remains on the backup server and only the REST port is exposed to the client. And once the backup server is compromized, there is little one can do.