Kind of an old rant for me, but here goes anyway:
Note: It’s important to start a post like this by acknowledging the many excellent decisions that went into the restic architecture, and the tremendous utility that it provides. Restic is awesome. Having said that, let’s look honestly at areas for improvement:
The fact that the repository uses a single master key is an awful security hole that compromises the security goals expressed in the threat model. Most importantly: once you give someone access to the repository, you can never revoke it. Disabling their password “feels” like revocation, but they’ve already retrieved the master key and will be able to access all of the data in this repository forever.
Past discussions of this topic have prompted suggestions of revoking file-read access (but the threat model explicitly allows untrusted third parties to read files) or to create a new repository with a new key (effective, but simultaneously beyond the application scope and cumbersome to achieve losslessly).
IMHO, the right answer is:
- The repository should support multiple master encryption keys (a “key list”) which are used on a blob-by-blob basis. Blobs are written using the newest key, but the old blobs can be decrypted with the matching key in the list.
- User keys should be asymmetric instead of symmetric. Each user’s public key is stored unprotected in the repo, and each user stores their private key externally
- When a new master encryption key is added to the key list, it is issued to intended users by storing it in each user’s keyfile, encrypted with that user’s public key (allowing them to retrieve it with their private key)
- Blobs can be migrated from old keys to the newest key
This approach will allow an administrator to revoke a user’s ability to decrypt the repository by issuing a new key to everyone but the revoked user.
- This will immediately prevent the user from decrypting new content
- The user will be able to continue decrypting old blobs (which we should assume he already copied while he had access anyway).
- If the admin desires, he can migrate old blobs to the new key, although this is optional. This will not impact users with access to the current key.