Re-encrypt a repository with a new key

[Ernest0x]

This would normally involve these steps:

1. Decrypt repository data with the old key
2. Re-encrypt decrypted repository data with new key
3. Replace old data (encrypted with the old key) with new data (encrypted with the new key)
4. Replace old key with new key

This feature is important in order to recover from a security compromise (if someone steals your repo keys).

Thinking of it now, step 2 is closely related to #82, so you could merge these issues, if that makes more sense.

[mappu]

I think LUKS may be a good inspiration - there is one aes key used for the repository data, and then in the metadata there are several "slots" where this key can be stored encrypted with multiple passphrases/keyfiles.

This would allow you to rotate passphrases/keyfiles in the event of a security breach without needing to rewrite the whole repository. It also has the advantage of not needing to decrypt data on untrusted storage, or to run a server process on dumb storage like S3 or FTP.

.

ASIDE: separating the actual aes key from the user's passphrase/keyfile has some other benefits too; combined with convergent encryption (deriving aes key from plaintext block), this even allows you to safely deduplicate between repositories with different passwords.

[Ernest0x]

@mappu if the key for data encryption does not change and the data is not re-encrypted, then an attacker that has compromised that key would still be able to decrypt the data. Re-encrypting the encryption key would protect from stealing that key again, but would not protect from the attacker decrypting the actual data, provided that he gets access to it.

I am not using LUKS, so I may miss some important information, but as you describe it, it seems that this multiple "slot" mechanism for storing the encryption key is not there to help in case of a key compromise, but to allow multiple users access the same encrypted data with different passwords/keyfiles.

[anarcat]

the idea of LUKS is that the whole filesystem cannot be easily re-encrypted. it's a separate operation. but the "keyfile" that is used to encrypt the filesystem is a large key that is then encrypted with the passphrase that you need to provide to decrypt the volume. i believe the multiple "slots" mechanisms are the different passphrases you can encrypt that keyfile with.

later cryptsetup releases added a "re-encrypt" option, but that's a new, and inherently slow process.

[skruppy]

In contrast to LUKS, which has to do the whole resigning process in place, attic has enough space to re-encrypt. Reasons to do so can be found in restic/restic#320.