feat!: add key commitment to database main key AEAD #5188
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Updates database encryption by adding key commitment to the main key authenticated encryption.
Motivation and Context
Most authenticated encryption with associated data (AEAD) constructions, including the
XChaCha20-Poly1305
construction used in the codebase, do not commit to keys. This is often not problematic, but in the context of password-based encryption, it can remove certain formal guarantees of authenticity.Recent work suggests that the use of a key-committing AEAD as part of a password-based encryption design can provide improved security against particular attacks. While these are likely entirely theoretical for Tari database encryption, it makes sense to consider feasible mitigations.
While key-committing AEADs are not standardized or widely available in libraries, one paper suggests a particularly simple design that augments an arbitrary AEAD by using a key derivation process that includes a particular hash commitment with the ciphertext.
This PR adds the hash-of-key design to the AEAD used for encryption of the database main key.
Here is a diagram showing the complete database encryption design. Rectangular nodes are secret data, rounded nodes are functions/algorithms, and cylindrical nodes are data stored in the database. Double-ended arrows indicate encryption/decryption functionality.
How Has This Been Tested?
Existing unit tests pass. A new unit test passes. Manually tested creating a new wallet, loading it successfully (with the correct passphrase) and unsuccessfully (with an incorrect passphrase), and performing a successful and unsuccessful (with incorrect existing passphrase, and with a mistyped new passphrase) passphrase change.
BREAKING CHANGE: This adds an encryption-related field to the database and modifies key derivation, so attempts to access existing databases will fail.