Setting restic password to maximize data security

Getting Help
1

The Restic documentation seems to give remarkably little guidance regarding how to set restic passwords to maximize data security. My understanding is that the restic password is used to derive the AES-256 data encryption/decryption key, which is 256 bits long. That being the case, to get the strongest cryptographic security, isn’t it necessary for the password to have at least 256 bits of entropy? For example, if the password comprises random alphanumeric characters, the password should be at least 43 characters long, since (26*2+10)^43^ = 2^256.03^. In other words, 43 alphanumeric characters gives just over 256 bits of entropy.

2

Hi @Bill

I see it this way: The whole idea of using a password in order to derive the AES encryption key is about using less entropy than 256 bits, i.e. a password which is in some way memorable.

If you need maximum security, i.e. a completely random key, the best solution would be to use the AES-256 key directly. This has the nice side effect that no computationally heavy key-derivation is needed. This speeds-up CLI calls and could make restic usable on very weak hardware (e.g. with hardware support for AES).

I opened a PR to restic some time ago allowing to directly use the “masterkey” (i.e a keyfile with the direct AES key and the parameters needed for the cryptographic verification). But it didn’t get much attention, so I assume it’s a design decision of restic maintainers to not allow this.

FWIW, rustic does support the restic style password-based credentials as well as masterkey credentials, see Managing Repository Keys - rustic user documentation

3

Two more things about security:

  • The masterkey which is used and which is derived from the password has a length of 512 bits (256 for AES-256 and 256 for the Poly1305AES MAC), so I assume that the password should be also of 512bits entropy in order to get “strongest cryptographic security”
  • In any case, using a password with whatever entropy gives you less security than locally storing and using the masterkey. Simply because the attack surface in the first case additionally involves the possibility of an attacker being able to break the key derivation algorithm.