I was reading the documentation about creating a repository with an empty password:
It’s not completely clear to me whether encryption is still enabled if I do not set a password when initializing the repo. My understanding is that restic always encrypts data, even with an empty password - but I want to confirm.
I have a use case where I am backing up to an already encrypted disk, so I don’t really need restic’s encryption protection. Is it possible to disable encryption completely in restic? Or is restic’s encryption mandatory and always-on?
You are correct. The encryption is active nonetheless, and you can’t disable it.
Please note that encryption uses hardware acceleration in the CPU, so it’s usually not a problem from a performance perspective.
Others have asked for ways to disable it, but as it stands now, encryption is such an integral part of restic that it isn’t on the radar to be able to disable it.
I’d go ahead with the repo on the encrypted disk regardless. Even if you dont feel that you need it, it shouldn’t be a problem performance wise.
The repository is always encrypted using a master encryption key. This happens both when using a real password and when using --insecure-no-password.
The only difference when using --insecure-no-password is that restic accepts an empty string as the password. But the deduplication, encryption, deduplication and compression works as usual.
Yes, you can change from an empty password to a non-empty one by running restic --insecure-no-password key passwd, which will ask you for a new password to use.
To add a bit more context to rawtaz’s answer, the keys you can manipulate with the key subcommand are basically all the same master encryption key, but that key is encrypted with a password. You can add multiple keys so you can access the repository with different passwords, but the master encryption key never changes – you are just creating another copy of the master encryption key that has itself been encrypted with a different password.
So, if you create a repository without any password, what you effectively have is a key object (just like if you used a password) but that stores the repository master encryption key in plaintext (not encrypted – or encrypted with a null key, which is exactly the same thing from a security perspective).
“Adding a password later” is then just adding a new key that is encrypted with a password and (crucially) deleting the plaintext key, though if the repository has ever been stored in an untrusted location (e.g. a cloud storage provider) then you should consider your repository already compromised because the provider had access to the plaintext master key at one point and you cannot prove they still don’t have a copy of that key somewhere.
Actually the key is still encrypted, but with a useless password (the snippet below is the result of creating a key with an emtpy password). So, the key is effectively plaintext, but without being obvious at first glance
