Feature Request: Detached Encryption Key

Just wondering if it’d be possible to get the option to detach the encryption key, and not keep this in the same location that the actual backup is? In this way, data could be stored in an untrusted location without risk of the encryption key being stolen and brute forced (even a decent password could be, eventually, brute forced by a large enough actor, I presume?). Thanks :slight_smile:

If you’re really afraid of someone brute-forcing your keyfile just use a long enough password with an entropy similar to the key stored therein (256 bit). Then it would be equally hard to brute force your password or the master key.
Otherwise you could also mount another file system in the keys directory.

Are you sure? I’m not a cryptography expert, but why couldn’t the adversary brute-force the key directly, rather than brute-forcing the password to decrypt the key? They don’t need an encrypted key to brute-force access to a repository.

I can see where you’re coming from, and I must say that it’s unlikely that we’ll add such a function to restic. It will make the code more complicated (every change does), and the security gain is minimal (at best).

I’ll try to explain. You’re right, every password can be found by brute force eventually. But that’s no different to the underlying encryption/signing keys for a repo. After all, there are “only” a finite number of possible values (2 to the power of 256, a really large number).

It’s not realistic to find the raw encryption key in a reasonable amount of time, so usually attackers try to find the password. In order to make this much harder, we’re using a strong Key Derivation Function called scrypt for this. It’ll require a lot CPU and memory, so for a single transition of password to key, more than 500ms of CPU time and about 100MiB of memory is needed.

So, it’s not realistic to find the password in reasonable time either. The only exception would be very very weak passwords, such as the empty string or very short words like foo.

In summary, as long as you have a password that is long enough (I recommend at least 20 characters), you’re safe, regardless where the key file is stored.

2 Likes

There is a protocol allowing that using public key cryptography.

You create RANDOM (instead of by key derivation) symmetric encryption keys (256 bit) - one per file, one per session, doesn’t matter really. Then you encrypt the encryption key with a public key which resides on the server, and attach the encrypted key to the files somehow (using an index of files, keys for example).

The private key associated with the public key can sit off-line completely, or can sit on the same computer but encrypted with a password. Either way, you can backup all you like without needing entering a key or password at all but you can only restore with the presence of the private key (if it’s off-line) or the password decrypting the private key (if it’s on the server).

Thank you for writing down your ideas. Something akin to this is tracked in https://github.com/restic/restic/issues/187 and https://github.com/restic/restic/issues/533, is a completely different issue.

Before discussing protocols and implementations, we need to clearly define what the threat model and the properties of the system are. Let’s do that in the appropriate issues when the time comes. Thanks!

Apologies for not responding earlier - I missed the reply. Thanks for your thorough explanation, and for clarifying why this is unlikely to be implemented. Much appreciated :slight_smile: