feat!: refactor database encryption

[AaronFeickert]

Description

Refactors database encryption to enable easier password changes and PBKDF parameter updates.

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) 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 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.

[hansieodendaal]

Nice. Please see some comments below.

[jorgeantonio21]

Really nice work ! Seems to be on the right track. I left a few minor comments.

[hansieodendaal]

utACK

[stringhandler]

ACK - tested locally.

When using it on an existing db, it just came back as wrong password. It's fine for now, since this will be a breaking change and there's no data at stake, but in future, we'll want to distinguish between version mismatches and incorrect passwords. Not sure if that is catered for here.

[AaronFeickert]

ACK - tested locally.

When using it on an existing db, it just came back as wrong password. It's fine for now, since this will be a breaking change and there's no data at stake, but in future, we'll want to distinguish between version mismatches and incorrect passwords. Not sure if that is catered for here.

It is accounted for to the extent possible. We store the parameter version in the clear, and a good future parameter update design will detect and support older versions (and perhaps even update automatically to the newest version), so "this version isn't supported" should never be a problem unless the user were to downgrade their client to one that doesn't support a newer parameter set used for their database.

However, malleation of the stored parameter version to a supported but incorrect value will result in a generic "bad passphrase" error. The key derivation function is such that we can't detect a bad key resulting from a bad passphrase from one resulting from different derivation parameters. (If we could, this would probably violate the guarantees you'd want from such a key.)

[AaronFeickert]

It was noted elsewhere that this design doesn't protect against the following scenario:

• The user chooses a weak passphrase for database encryption.
• An attacker obtains the database and is able to decrypt it using brute force.
• The user changes their passphrase to a better one.
• The attacker obtains the new database and is able to decrypt it using the same main key.

If this threat model is of concern, it is possible to include functionality that chooses a new main key and re-encrypts the database with it. Like password change functionality, this is supported by the new design but not implemented here. It may be useful to present this as an option to the user. It is the case that persistent access to the encrypted database is a different threat model than one-time access.