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 the use of
CoreTransactionAEADKey
andCommsNoiseKey
to be populated in place. SwitchesCommsNoiseKey
to use aSafeArray
under the hood.Extends the work of PR 4967.
Motivation and Context
Earlier work updates the use of keys for value encryption and Noise. Value encryption keys use a
SafeArray
type in aHidden
wrapper, and Noise keys use aHidden
array. However, in both cases, a copy of the hash output used to populate the keys is left in memory.This work mitigates the problem. Because the hashing API now supports in-place output finalization via
finalize_into
andfinalize_into_reset
, we can populate keys directly by mutable reference.It also renames
CoreTransactionAEADKey
toEncryptedValueKey
for clarity, and switchesCommsNoiseKey
to be aSafeArray
under the hood. There is discussion on whetherCommsNoiseKey
needs to be aSafeArray
; while the reasoning makes sense, I still think it's good practice to take advantage of the benefits ofSafeArray
for array-like key types unless there's a compelling performance reason otherwise. Discussion on this is welcome!How Has This Been Tested?
Existing tests pass.