Questions and thoughts on restic security - revocable keys and cryptoperiods

[fd0]

@David

Currently, the design documentation currently says:

The restic backup program guarantees…accessing the unencrypted content of stored files and metadata should not be possible without a password for the repository

But it does not mention that once a password is shared with a user, repository access cannot be revoked from that user or anyone he shares the key with. This should be explicitly mentioned, especially since the restic key remove function implies security.

You’re right, the design document simplifies here. Thanks for pointing that out.

@David

This seems contradictory to the restic threat model, which states that the “design goals for restic include being able to securely store backups in a location that is not completely trusted, e.g. a shared system where others can potentially access the files”

Again, a simplification. What I meant when I wrote the document was that restic enables storing data on a system that is not completely trusted and nobody is able to access the data if they weren’t given access. Or something along those lines. I think you see where I’m coming from

@David

Would it be something like the following?

You list some great solutions, but they all have in common that complexity is added to restic and the repository format. I’m not judging, I’m just pointing it out.

@David

I am pretty impressed with the implementation

Oh, thanks for the praise! Just to give you a bit of background on me: I’ve been working as a penetration tester for the last decade or so, so I’m regularly breaking stuff in my dayjob. That has helped tremendously when designing restic, of course. I’m not an expert on cryptography, but I understand the math and I’m regularly breaking real-life crypto systems, so I’m familiar with implementation issues and errors. And I fully agree with you: key management is a major headache

@David

But I think it’s important for users to understand that restic key remove doesn’t really improve security, and that some of the statements in the documentation are likely to mislead users into thinking their repository is more secure than it actually is. (For example, you had such an impression when you wrote your message above!)

I can see your point. In hindsight, I regret some aspects of how restic is built, this is one of them. I think it would be great if we could improve the documentation and the CLI so that it becomes clearer. People regularly don’t get it until you explain the gritty details to them (which should not be necessary). I took a lot of inspiration from existing crypto systems, especially LUKS for Linux, which works exactly the same way as restic.

@David

In the big picture, I think there are two ways to proceed:

In my opinion, we should improve the documentation, especially the threat model section. In a second step we can then discuss if we want to extend restic (and thereby increasing its complexity) or if we want to live with restic’s limitations.