Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat!: refactor database encryption (#5154)
Description --- Refactors database encryption to enable easier [password changes](#5003) and [PBKDF parameter updates](#5151). BREAKING CHANGE: This significantly changes how database encryption is performed, so existing databases will be rendered permanently inaccessible. Motivation and Context --- Currently, the user's passphrase is used with a PBKDF (as of now, `Argon2` with [recommended parameters](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id)) to derive the `XChaCha20-Poly1305` key used for database encryption. While this is a safe way to handle database encryption (up to the complexity of the passphrase), it is brittle. Changing the passphrase or updating the PBKDF parameters would require that all database entries be re-encrypted with a new key, which is likely to be tedious and prone to corruption. This can be [improved](#5151 (comment)) by refactoring how encryption is done. When the user wishes to set up encryption, we generate a high-entropy random `XChaCha20-Poly1305` key (the _main key_) to do the actual authenticated encryption of database entries. We then run the user's passphrase and a random salt through the PBKDF to derive another `XChaCha20-Poly1305` key (the _secondary key_), and encrypt the main key with authentication. Finally, we store the secondary key salt, the encrypted main key, and a version identifier in the database. When we need to decrypt database entries, we derive the secondary key using the salt (and parameters from the version identifier), decrypt and authenticate the main key, and use the main key for database operations. When the user decides to change their passphrase, or if we wish to update the PBKDF parameters, we simply derive a new secondary key, re-encrypt the main key with it, and store the new secondary key salt, encrypted main key, and version identifier. This operation can be done quickly and with minimal risk. This PR includes the refactoring needed to support this two-key design. However, it does not directly integrate password change or PBKDF parameter update functionality, which is deferred to future work. How Has This Been Tested? --- Existing tests pass. Manual testing is still needed. BREAKING CHANGE: This significantly changes how database encryption is performed, so existing databases will be rendered permanently inaccessible.
- Loading branch information